How Hacktron provides 24/7 security for Rocket.Chat

06.30.2026
Rocket.Chat
Hacktron Review

11 min

1-2 minutes on average: to review a PR for security issues
17 real vulnerabilities: found and triaged in first 20 days
73% of issues found: were actionable and addressed

“We’re now able to scale security scanning across all of our PRs.

“Hacktron flags potential issues, letting us focus our review effort on the pull requests that need closer attention.”

Julio Araujo
Director of Security

About Rocket.Chat

Rocket.Chat is an open-source, fully customizable communications platform used by government, defense, and enterprise teams worldwide. Security is a top priority for software at this scale and size and one of the cheapest places to catch security vulnerabilities is early in software development lifecycle, through better design and continuous code reviews before it reaches production.

The challenge: a growing gap between code velocity and security review

However, even before AI, the developer to security-engineer ratio made it impractical to meticulously review every PR for vulnerabilities. Now that AI is accelerating how fast code gets written and shipped, reviewing every change for security has become more crucial than ever.

“We simply don’t have enough engineers to perform a thorough review of every PR. Traditional SAST, SCA, and secrets-scanning tools can be very useful, and we still use them, but they often lack the context needed to identify complex issues like business-logic vulnerabilities.

“They also struggle to reason across multiple steps or chain vulnerabilities together to understand how a system could actually be exploited.”

Julio Araujo
Director of Security

Scaling security review across every PR with Hacktron

To close that gap, Rocket.Chat uses Hacktron Review for continuous, 24/7 code and security review, helping catch expensive vulnerabilities before they reach production.

For every PR, Hacktron:

Performs a deep security review of the code changes.
Flags vulnerabilities directly in the PR with clear comments.
Enables developers to fix actionable issues before merging.
Helps the security team track and batch lower-priority findings for periodic remediation.
Keeps security review continuous, instead of relying only on periodic audits or manual reviews.

“Hacktron learns from our codebase and feedback over time.

“As we provide more context about intended functionality, accepted risks, and security requirements, false positives become less frequent, improving accuracy and cutting the time spent triaging non-issues.”

Julio Araujo
Director of Security

Let’s walk through an analysis of Hacktron’s reviews on Rocket.Chat: what kinds of vulnerabilities it finds, how accurate those findings are, and how it helps the team ship faster. Over the first 20 days, it reviewed 155 PRs and surfaced real issues. These include a critical authorization bug that would have let any logged-in user download another user’s full data export, two critical Apple OAuth flaws that weakened the login boundary across deployments, and a few XSS vulnerabilities.

Analysis of findings

Over the first 20 days (June 5–25, 2026), Hacktron reviewed every pull request as it came in, running 490 scans over 10,744 changed files. Here’s a breakdown of PRs reviewed, issues found, how they were triaged, and the real severity of the true positives.

Every PR was reviewed automatically, and the reviews themselves ran in ~1–2 minutes for a typical PR (a median of 1.4 minutes, and 5.3 minutes at the 95th percentile), fast enough to sit in CI without slowing anyone down. However, it is important to note that if a PR has a lot of changes, Hacktron takes its time to be thorough in its testing.

What kinds of vulnerabilities does it find?

Now, the important question is what kind of vulnerabilities it caught. Hacktron isn’t just a pattern-matcher; it reads and reasons about the code just like a security researcher. So the findings spanned most of the OWASP Top 10: broken access control, authentication/2FA bypasses, XSS, SSRF/open-redirect, cryptographic failures, secret exposure, and business-logic flaws.

Let’s get into the details of the top 3 vulnerabilities that Hacktron caught.

Account takeover via Apple OAuth

This is the first vulnerability Hacktron found right after Rocket.Chat integrated it into their workflows, and it’s a very elegant and critical bug.

One important detail here is that Hacktron found a bug outside of the PR changes. The reason for this is that Hacktron’s reviews are not narrowly limited to the PR diff; it navigates dependencies and effects across the whole codebase to find second-order vulnerabilities.

High

Account Takeover via Unverified Email in Apple OAuth Login

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

The Apple OAuth login handler in loginHandler.ts contains a vulnerability where it trusts a client-provided email address if the Apple identity token does not contain one. Because the client-provided email field in the loginRequest is not cryptographically verified, an attacker can supply an arbitrary email address (e.g., a victim’s email). The accounts_meld.js hook will then use this unverified email to look up an existing user and link the attacker’s Apple service ID to the victim’s account. This allows the attacker to log into the victim’s account using their own Apple ID, leading to a full account takeover.

Steps to Reproduce

The attacker initiates an Apple login using their own Apple ID, ensuring that the Apple identityToken does not contain an email claim (e.g., by using an Apple ID that hasn’t shared its email, or during a subsequent login where Apple omits the email).
The attacker intercepts the login request sent to the Rocket.Chat server (e.g., the DDP login method call).
The attacker modifies the loginRequest payload to include the victim’s email address in the email field: {"identityToken": "<attacker_token>", "email": "victim@example.com", "fullName": {...}}.
The server processes the request. In loginHandler.ts, serviceData.email is empty, so it assigns serviceData.email = email (the victim’s email).
The accounts_meld.js hook looks up the user by the victim’s email, finds the victim’s account, and links the attacker’s Apple ID to it (Users.setServiceId(user._id, serviceName, serviceData.id)).
The attacker is now logged into the victim’s account and can access it at any time using their Apple ID.

In apps/meteor/app/apple/server/loginHandler.ts, the Apple Sign-In flow fell back to a client-supplied email when the Apple JWT didn’t contain one:

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

An attacker could forge an Apple JWT with no email claim and supply an arbitrary email in the request, letting them authenticate as any user. Rocket.Chat published this as a Critical advisory (GHSA-wx3c-76rf-wpwf, CVE-2026-55666) as the vulnerability existed in pre-existing code.

There was another bug in the same handler: it verified the JWT signature but skipped claims validation. It used JWS.verify (signature only) instead of JWS.verifyJWT, and never checked aud, exp, or nbf. Any Apple-signed token with a non-empty iss was accepted, so a leaked or cross-audience token could be replayed to log in as the victim, with no expiry on the replay window. Rocket.Chat published this as a High advisory (GHSA-c75c-5hc7-j4vp, CVE-2026-55759).

Critical

Missing JWT Audience (aud) Validation in Apple Identity Token Handler Leads to Account Takeover

The handlePassportIdentityToken function in apps/meteor/app/apple/lib/handlePassportIdentityToken.ts is responsible for parsing and validating Apple Identity Tokens during the Passport.js-based Apple Sign-In flow (apps/meteor/app/apple/server/applePassportOAuth.ts). While it correctly validates the token’s cryptographic signature, issuer (iss), and expiration (exp), it fails to validate the audience (aud) claim.

In JWT-based authentication flows like OpenID Connect, the aud claim indicates the intended recipient of the token (the Client ID). Without validating that the aud matches the Rocket.Chat instance’s configured Apple Client ID, the application will accept any valid Apple Identity Token.

An attacker can exploit this by creating their own application with “Sign in with Apple” enabled. When a victim logs into the attacker’s application, the attacker receives a valid Apple Identity Token for that victim. The attacker can then submit this token to the Rocket.Chat server’s Apple OAuth callback endpoint. Because the token is genuinely signed by Apple, has a valid issuer, and is not expired, handlePassportIdentityToken will return the victim’s data. The upstream Passport strategy (AppleStrategy in applePassportOAuth.ts) then uses this data to log the attacker in as the victim, leading to complete account takeover.

Note that another function, handleIdentityToken in apps/meteor/app/apple/lib/handleIdentityToken.ts, correctly implements audience validation, but handlePassportIdentityToken completely omits it.

Any user could download another user’s data export

In the GDPR data-export download path, the access check was called without the file object, so it fell open and authorized any logged-in user. With a valid export file ID, an attacker could pull another user’s full data export: private messages, profile, and room data. Caught in PR #40889 and fixed before merge.

Critical

Broken Object Level Authorization (BOLA) in UserDataFiles Allows Any Authenticated User to Download GDPR Data Exports

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

An authorization bypass vulnerability exists in the file-upload access control mechanism of Rocket.Chat. When a user requests to download a file from the UserDataFiles collection (which contains highly sensitive GDPR data exports of users, including private messages, direct messages, and personal data), the server fails to validate whether the requesting user is the owner of the data export.

The result: a stronger security posture, and less time spent triaging non-issues

For Rocket.Chat, the biggest impact is leverage. Hacktron gives the security team a way to apply expert review consistently across the development workflow, without turning security into a blocker for engineering velocity.

The result is a tighter feedback loop between engineering and security: vulnerabilities are caught earlier, developers get clearer guidance at the point of change, and the security team spends less time sorting through noise and more time on the issues that genuinely matter.