Rocket.Chat 的 7×24 小时安全保障

2026.06.30
Rocket.Chat
Hacktron Review

2分钟

平均 1–2 分钟: 完成一个 PR 的安全审查
17 个真实漏洞: 前 20 天内发现并完成分类处理
73% 的问题: 需要处理，且都已处理

“现在我们能把安全扫描铺到所有 PR 上。

“Hacktron 会标出潜在问题，我们就能把审查精力集中在真正需要细看的 PR 上。”

Julio Araujo
安全总监

关于 Rocket.Chat

Rocket.Chat 是一个开源、可完全定制的通信平台，全球的政府、国防和企业团队都在使用。对这种规模的软件来说，安全是重中之重。而发现安全漏洞成本最低的阶段之一，是软件开发生命周期的早期：在代码进入生产环境之前，靠更好的设计和持续的代码审查把问题拦下来。

挑战：代码越写越快，安全审查跟不上

但即使在 AI 出现之前，开发人员和安全工程师的人数配比，就已经让逐个细审每个 PR 变得不现实。如今 AI 让代码写得更快、交付得更快，对每次改动做安全审查比以往任何时候都更重要。

“我们根本没有足够的工程师把每个 PR 都彻底审一遍。传统的 SAST、SCA 和密钥扫描工具很有用，我们也还在用，但它们往往缺少上下文，识别不了业务逻辑漏洞这类复杂问题。

“它们也很难做多步推理，或者把多个漏洞串成利用链，看清系统实际上会怎样被攻破。”

Julio Araujo
安全总监

用 Hacktron 把安全审查覆盖到每个 PR

为了补上这个缺口，Rocket.Chat 用 Hacktron Review 做 7×24 小时持续的代码与安全审查，在代码进入生产环境之前发现代价高昂的漏洞。

对每个 PR，Hacktron 会：

对代码改动做深度安全审查。
直接在 PR 中用清晰的评论标出漏洞。
让开发人员在合并前修复需要处理的问题。
帮安全团队跟踪优先级较低的问题，攒起来定期集中修复。
让安全审查持续进行，不再只靠定期审计或人工审查。

“Hacktron 会持续从我们的代码库和反馈中学习。

“我们提供的预期功能、已接受风险和安全要求等上下文越多，误报就越少，准确率越高，花在分类处理无效问题上的时间也越少。”

Julio Araujo
安全总监

下面具体看看 Hacktron 在 Rocket.Chat 上的审查：能发现哪些漏洞、准确率如何、怎样帮团队更快交付。前 20 天里，它审查了 155 个 PR，发现了真实存在的问题，包括：一个严重的越权漏洞，任何已登录用户都能借此下载其他用户的完整数据导出；两个严重的 Apple OAuth 缺陷，削弱了各个部署的登录边界；以及几个 XSS 漏洞。

问题分析

前 20 天（2026 年 6 月 5 日至 25 日），每个 PR 一提交，Hacktron 就开始审查，共对 10,744 个改动文件运行了 490 次扫描。下面按审查的 PR、发现的问题、分类处理结果和真实漏洞的实际严重程度逐项拆解。

每个 PR 都自动审查，典型 PR 的审查只需约 1–2 分钟（中位数 1.4 分钟，P95 为 5.3 分钟），放进 CI 也不会拖慢任何人。需要说明的是，如果一个 PR 改动很多，Hacktron 会多花些时间，把测试做彻底。

能发现哪些漏洞？

关键问题是：它到底抓到了哪些漏洞。Hacktron 不只是做模式匹配，它会像安全研究员一样阅读代码、推理代码。所以发现的问题覆盖了 OWASP Top 10 的大部分类别：访问控制缺陷、认证/2FA 绕过、XSS、SSRF/开放重定向、加密机制失效、密钥泄露和业务逻辑漏洞。

下面详细看看 Hacktron 抓到的 3 个最重要的漏洞。

Apple OAuth 账户接管

这是 Rocket.Chat 刚把 Hacktron 接入工作流后，Hacktron 发现的第一个漏洞。它的利用思路非常巧妙，危害也很严重。

值得注意的是，这个漏洞并不在 PR 的改动范围内。Hacktron 的审查不局限于 PR diff，它会在整个代码库中梳理依赖关系和影响范围，找出二阶漏洞。

高危

Apple OAuth 登录使用未验证邮箱，可导致账户接管

apps/meteor/app/apple/server/loginHandler.ts:32-35

loginHandler.ts 中的 Apple OAuth 登录处理逻辑存在漏洞：如果 Apple 身份令牌里没有邮箱地址，它会直接信任客户端提供的邮箱。由于 loginRequest 中客户端提供的 email 字段没有经过密码学验证，攻击者可以填入任意邮箱地址（例如受害者的邮箱）。随后，accounts_meld.js 钩子会用这个未经验证的邮箱查找已有用户，并把攻击者的 Apple 服务 ID 绑定到受害者账户上。攻击者因此可以用自己的 Apple ID 登录受害者账户，实现完整的账户接管。

复现步骤

攻击者用自己的 Apple ID 发起 Apple 登录，并确保 Apple identityToken 中不含 email 声明（例如使用未共享邮箱的 Apple ID，或在 Apple 省略邮箱的后续登录中）。
攻击者拦截发往 Rocket.Chat 服务器的登录请求（例如 DDP login 方法调用）。
攻击者修改 loginRequest 载荷，在 email 字段填入受害者的邮箱地址：{"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}。
服务器处理该请求。在 loginHandler.ts 中，serviceData.email 为空，于是执行 serviceData.email = email（即受害者的邮箱）。
accounts_meld.js 钩子按受害者邮箱查找用户，找到受害者账户，并把攻击者的 Apple ID 绑定上去（Users.setServiceId(user._id, serviceName, serviceData.id)）。
攻击者此时已登录受害者账户，之后随时都能用自己的 Apple ID 访问。

在 apps/meteor/app/apple/server/loginHandler.ts 中，如果 Apple JWT 不含邮箱，Apple 登录流程会退而使用客户端提供的邮箱：

32
const serviceData = await handleIdentityToken(identityToken);
33
if (!serviceData.email && email) {
34
    serviceData.email = email;   // attacker-controlled fallback
35
}

攻击者可以伪造一个不含邮箱声明的 Apple JWT，再在请求里填入任意 email，就能以任意用户身份通过认证。由于漏洞存在于已有代码中，Rocket.Chat 将其作为严重级别安全公告发布（GHSA-wx3c-76rf-wpwf，CVE-2026-55666）。

Apple 登录跳过 JWT 声明校验

同一个处理逻辑里还有另一个漏洞：它验证了 JWT 签名，却跳过了声明校验。代码用的是 JWS.verify（只验证签名），而不是 JWS.verifyJWT，也从未检查 aud、exp 或 nbf。只要是 Apple 签名、iss 非空的令牌都会被接受，因此泄露的令牌或签发给其他受众的令牌都能被重放，以受害者身份登录，而且重放窗口不会过期。Rocket.Chat 将其作为高危级别安全公告发布（GHSA-c75c-5hc7-j4vp，CVE-2026-55759）。

严重

Apple 身份令牌处理函数未校验 JWT 受众（aud），可导致账户接管

apps/meteor/app/apple/lib/handlePassportIdentityToken.ts 中的 handlePassportIdentityToken 函数，负责在基于 Passport.js 的 Apple 登录流程（apps/meteor/app/apple/server/applePassportOAuth.ts）中解析和校验 Apple 身份令牌。它正确校验了令牌的密码学签名、签发者（iss）和过期时间（exp），却没有校验受众（aud）声明。

在 OpenID Connect 这类基于 JWT 的认证流程中，aud 声明表示令牌的预期接收方（即 Client ID）。如果不校验 aud 是否与 Rocket.Chat 实例配置的 Apple Client ID 一致，应用就会接受任何有效的 Apple 身份令牌。

攻击者可以自己创建一个开启“通过 Apple 登录”的应用来利用这一点。受害者登录攻击者的应用后，攻击者就拿到了该受害者的有效 Apple 身份令牌，再把它提交到 Rocket.Chat 服务器的 Apple OAuth 回调接口。由于令牌确实由 Apple 签名、签发者有效且未过期，handlePassportIdentityToken 会返回受害者的数据。上游的 Passport 策略（applePassportOAuth.ts 中的 AppleStrategy）随后用这些数据让攻击者以受害者身份登录，导致账户被完全接管。

注意，apps/meteor/app/apple/lib/handleIdentityToken.ts 中的另一个函数 handleIdentityToken 正确实现了受众校验，而 handlePassportIdentityToken 完全漏掉了这一步。

任意用户可下载他人的数据导出

在 GDPR 数据导出的下载路径中，访问检查调用时没有传入文件对象，结果检查默认放行，任何已登录用户都能通过授权。只要拿到有效的导出文件 ID，攻击者就能拉取其他用户的完整数据导出：私密消息、个人资料和房间数据。在 PR #40889 中发现，合并前已修复。

严重

UserDataFiles 存在对象级越权（BOLA），任意已认证用户都能下载 GDPR 数据导出

apps/meteor/app/file-upload/server/lib/FileUpload.ts:472

Rocket.Chat 的文件上传访问控制机制存在授权绕过漏洞。用户请求从 UserDataFiles 集合下载文件时（该集合存放用户高度敏感的 GDPR 数据导出，包括私密消息、私信和个人数据），服务器没有校验请求者是否为该数据导出的所有者。

成效：安全态势更强，少在无效问题上耗时间

对 Rocket.Chat 来说，最大的价值在于放大了安全团队的能力。Hacktron 让安全团队能在整个开发流程中稳定地提供专家级审查，又不会让安全拖慢工程速度。

结果是工程和安全之间的反馈闭环更紧了：漏洞发现得更早，开发人员在改代码时就能拿到更清晰的指导，安全团队少花时间筛噪音，把更多精力放在真正重要的问题上。