Rocket.Chat CVE-2026-28514: a missing await made every password valid

CVE-2026-28514 in Rocket.Chat is a rare critical vulnerability caused by one missing asynchronous operation. In the enterprise ddp-streamer service, the password comparison returned Promise<boolean> but the caller omitted await. A Promise object is truthy in JavaScript, so the wrong-password rejection did not run for an account with a password hash.

GitHub Security Lab tested version 7.13.2 and documented login as any known password-based user using an arbitrary string. Rocket.Chat released an initial fix in 8.0.0 on 12 January 2026 and fixes for other supported branches on 5 March. Administrators should follow Rocket.Chat’s security matrix rather than assuming any later 7.x build is safe.

A second flaw amplified the first

The same work found CVE-2026-30833, NoSQL injection in the username field. Input reached a MongoDB selector without enforced string typing, allowing an operator expression to select an unintended record. Combined with CVE-2026-28514, an actor did not need to know the full username.

The exposed path was a login method in ddp-streamer reachable over WebSocket. Do not generalise the finding to every Community Edition deployment; the advisory covers a particular enterprise component. First establish whether the service is enabled and reachable.

Closing and investigating exposure

Update every node, restart processes and verify the live version. If patching needs a window, remove external access to ddp-streamer and restrict WebSocket at the reverse proxy. A WAF does not fix authentication logic but can reduce immediate reach.

Assume potential account takeover:

• revoke sessions and API tokens,
• inspect WebSocket logins from new addresses,
• review role, integration, webhook and application changes,
• rotate secrets exposed in channels or integrations,
• hunt for exports and bulk message reads.

The issue was found using GitHub Security Lab’s agentic framework and manually verified. That is the right model: AI can flag a suspicious flow, but a human must confirm reachability, impact and conditions. Our AI-assisted security review analysis covers the operating model.

For developers, enforce floating-Promise lint rules, negative authentication tests and strict boundary types. “A wrong password must fail” belongs in every regression suite. We can test this bug class across applications and APIs.

Why TypeScript did not stop it automatically

Promise<boolean> and boolean differ, but JavaScript permits objects in conditions. The compiler may not fail without ESLint rules for misused or unhandled Promises, and warnings help only when CI blocks on them.

For a critical authentication function:

1. Verify the hash exists.
2. Explicitly await comparison.
3. Enforce a boolean result.
4. Return one error that does not reveal account existence.
5. Audit the decision without the password or hash.

A unit test needs valid and invalid passwords. An integration test must cross the real WebSocket and microservice because the defect sat at a component boundary rather than inside bcrypt.

NoSQL injection is a type problem

Filtering characters such as $ is fragile. Username must be a normalised, bounded string, and an object or array should fail before reaching the query builder. Share the same validation schema across REST, DDP and internal messages.

Reconstructing scope after patching

Hunt successful sessions preceded by varying passwords, new IPs or client fingerprints. Compare account activity with the user’s presence. Treat every unexplained administrator success as potential compromise and inspect global changes.

Is a universal password reset enough? No. The vulnerable service accepted arbitrary passwords, so first patch and close the path, then revoke sessions and rotate.

Secure-development lesson

Authentication code should have an owner and a higher review bar than ordinary business logic. Password, token or user-selector changes need two reviewers, the full negative test suite and analysis across product editions.

Add mutation testing that deliberately removes await, reverses a condition or replaces the result with a constant. If tests still pass, they do not enforce the security property. A “supporting” microservice needs the same authentication standard as the main application.

---

Primary sources: GitHub Security Lab — CVE-2026-28514 and CVE-2026-30833, GitHub — AI-powered vulnerability research framework.