Sign In with ANY Password: How a Missing "await" Broke Rocket.Chat Authentication (CVE-2026-28514)

One Missing Word, Total Authentication Bypass

A single missing await keyword in Rocket.Chat's codebase meant that anyone could log into any account using literally any password. Not a weak password. Not a guessed password. Any password. The string "banana" would work just as well as the correct one.

This is CVE-2026-28514, a critical authentication bypass vulnerability discovered by GitHub Security Lab using their open-source AI-powered security research framework. It carries a CVSSv4 score of 9.3 out of 10, and it affected every Rocket.Chat version prior to 8.0.0 across multiple release branches.

Put simply: if an attacker knew a username — and usernames are often guessable or publicly visible — they owned that account.

How a Promise Object Replaced Actual Security

The root cause is almost comically simple to explain, which makes it all the more alarming.

Rocket.Chat's account service within the DDP streamer microservice calls an asynchronous function to validate passwords. Asynchronous functions in JavaScript return Promise objects. To get the actual result — the true or false answer of "is this the right password?" — the code needs to await that Promise.

The await keyword was missing.

Without it, the code evaluated the Promise object itself instead of waiting for the boolean result. A Promise object in JavaScript is always "truthy" — meaning the authentication check always passed, regardless of what password was submitted.

Think of it like a security guard who asks for your badge, but then waves you through before actually looking at it. The guard exists. The process exists. But the verification step gets skipped entirely.

According to the NVD description, this vulnerability "may lead to account takeover of any user whose username is known or guessable." That understates the severity. In most Rocket.Chat deployments, usernames are visible in channels, in profiles, and through the platform's user directory.

What an Attacker Could Actually Do

GitHub Security Lab confirmed that exploitation was straightforward. They connected to the WebSocket endpoint for the DDP streamer service, authenticated with an arbitrary password, and gained full access. Once signed in, the attacker could:

• Read messages across any channel the compromised user had access to
• Join and monitor channels, including private ones
• Impersonate users — sending messages as them, modifying settings, escalating privileges
• Access admin accounts if an admin username was known

GitHub's team demonstrated receiving live messages on the "General" channel after authenticating with a fabricated password. The attack required no special tools — just a WebSocket connection and knowledge of a valid username.

How AI Found What Human Reviews Missed

What makes this story particularly relevant for businesses is how the vulnerability was discovered. GitHub Security Lab built an open-source AI-powered framework designed to assist security researchers in finding vulnerabilities at scale. They pointed it at Rocket.Chat, and the framework flagged the authentication bypass.

As described in GitHub's blog post, the AI agent returned a note reading:

VULNERABILITY: password authentication bypass in account-service allows logging in as any user with a password set.

The researchers themselves admitted they found it "hard to believe at first." But manual verification confirmed the finding immediately.

Honest take: this vulnerability existed across multiple major version branches of a widely-used enterprise communication platform. Human code reviewers, automated linting tools, and traditional static analysis all missed it. A missing await is syntactically valid JavaScript — the code runs without errors, passes type checks, and produces no warnings. It just happens to skip the entire point of the function.

This is exactly the class of bug that AI-assisted security research excels at catching: subtle logical errors that hide in plain sight within large codebases.

It Wasn't the Only Finding

CVE-2026-28514 was the headline vulnerability, but GitHub Security Lab's framework uncovered additional issues. The blog post notes these were "authorization logic bugs" that "had been undiscovered for years."

Separately, researchers have also identified significant weaknesses in Rocket.Chat's end-to-end encryption (E2EE) implementation. A detailed analysis published by academic researchers found:

• Weak E2EE password generation: The mobile app's password generation algorithm applies toLowerCase() to what should be alphanumeric output, significantly reducing the keyspace
• Offline brute-force attacks: The private-key backup mechanism enables offline attacks because the initial E2EE password space is too small
• Ciphertext malleability: AES-CBC encryption without a MAC allows attackers to forge valid encrypted message blocks containing arbitrary text after observing a single ciphertext
• No key rotation on password reset: Compromised group keys remain valid even after a user resets their E2EE password

Additionally, CVE-2026-23477 revealed an information disclosure flaw where the /api/v1/oauth-apps.get endpoint exposed OAuth application credentials to unauthorized users, patched in version 6.12.0.

Real numbers: the EPSS (Exploit Prediction Scoring System) score for CVE-2026-28514 stands at 0.00110, and the vulnerability has a VMScore of 1000 on Vulmon — indicating maximum severity in their scoring model.

Which Versions Are Affected and What to Do

The vulnerability affects all Rocket.Chat versions prior to the following patched releases:

Here is what we recommend:

1. Update immediately. This is not a "schedule it for next sprint" vulnerability. Any password works. If the DDP streamer service is network-accessible, the instance is compromised until patched.
2. Audit access logs. Look for unusual login patterns — multiple accounts accessed from the same IP, logins from unexpected locations, or access to channels outside a user's normal pattern.
3. Review DDP streamer exposure. Determine whether the WebSocket endpoint for the DDP streamer is exposed to the internet or restricted to internal networks. Even with the patch applied, minimizing the attack surface is sound practice.
4. Rotate credentials. If running an unpatched version, assume compromise is possible. Reset passwords, rotate API keys, and review OAuth application credentials.
5. Evaluate E2EE reliance. If the organization depends on Rocket.Chat's end-to-end encryption for sensitive communications, the academic findings on E2EE weaknesses warrant a separate risk assessment.

What This Means for Your Project

Key takeaway for business: this incident illustrates three things that matter beyond Rocket.Chat itself.

First, trivial bugs cause catastrophic failures. A single missing keyword — five characters — eliminated all authentication for an enterprise communication platform. Security is not about exotic attack vectors. It is often about mundane oversights in critical code paths. Every async function call that handles authentication, authorization, or data validation is a potential CVE if the await is dropped.

Second, AI-assisted security tooling has arrived. GitHub Security Lab's framework found a vulnerability class that traditional tools and manual reviews missed for years. Organizations running open-source infrastructure should consider integrating AI-powered code analysis into their security workflows — not as a replacement for human researchers, but as a force multiplier that catches what humans skip.

Third, self-hosted does not mean self-secured. Rocket.Chat is popular precisely because organizations can run it on their own infrastructure for compliance and data sovereignty reasons. But self-hosting shifts the patching burden entirely onto the organization. If the security team is not tracking CVEs for every self-hosted component, the "secure" self-hosted platform may be less secure than a managed SaaS alternative that patches automatically.

Frequently Asked Questions

How does the missing await keyword cause authentication to bypass?

In JavaScript, async functions return Promise objects. When the await keyword is omitted, the code evaluates the Promise object itself rather than the resolved boolean value. Since any object in JavaScript is "truthy," the password check always passes — regardless of what password is submitted. The function to validate the password exists and runs, but its result is never actually checked.

Can attackers enumerate valid usernames to target accounts?

In most Rocket.Chat deployments, usernames are visible through channel member lists, user directories, and profile pages. The platform is a communication tool — usernames are designed to be discoverable. This means the only barrier to exploitation (knowing a valid username) is effectively no barrier at all in typical configurations.

What are the specific affected versions and patches?

Every Rocket.Chat version prior to 7.8.6, 7.9.8, 7.10.7, 7.11.4, 7.12.4, 7.13.3, and 8.0.0 is vulnerable. The fix was applied across all supported release branches simultaneously. Organizations should update to the latest available version within their release branch or upgrade to 8.0.0+.

Does the DDP streamer service require authentication to connect?

The DDP streamer service accepts WebSocket connections, and the authentication bypass occurs during the login process within that service. An unauthenticated user can connect to the WebSocket endpoint and then exploit the vulnerability to authenticate as any user with a password set. No prior authentication is required to reach the vulnerable code path.

How can organizations detect if they have been compromised?

Review authentication logs for anomalies: logins from unusual IP addresses, access to accounts that are typically inactive, or patterns showing sequential access to multiple accounts from the same source. Since the exploit leaves normal-looking login events (the authentication "succeeds"), detection requires behavioral analysis rather than looking for failed login attempts.