CVE-2026-28514 is a critical (CVSS 9.8) authentication bypass in the ddp-streamer service of Rocket.Chat. Because of a missing await, any password was accepted for an account that has one. Fixed releases are 7.8.6, 7.9.8, 7.10.7, 7.11.4, 7.12.4, 7.13.3 and 8.0.0.
What's affected
The GitHub advisory lists these versions as affected: everything before 8.0.0, 7.13.3, 7.12.4, 7.11.4, 7.10.7, 7.9.8 and 7.8.6, within each release line. Patched versions are 8.0.0, 7.13.3, 7.12.4, 7.11.4, 7.10.7, 7.9.8 and 7.8.6.
The advisory title says the issue is in the EE ddp-streamer-service, the enterprise micro service. If you do not run that service you should confirm that with Rocket.Chat before assuming you are safe.
How to check if you're exposed
Find your Rocket.Chat version from Administration, then Info in the admin UI, or check the image tag you deploy:
docker ps --format '{{.Image}}' | grep -i rocket
Compare it with the patched version for your release line. Also check whether you deploy the micro services layout that includes the ddp-streamer service. Microservice deployments are where the advisory places the flaw.
What to do now
- Upgrade to the fixed version for your line: 7.8.6, 7.9.8, 7.10.7, 7.11.4, 7.12.4, 7.13.3 or 8.0.0.
- Redeploy every service in the micro services set, not only the main app, so no old ddp-streamer instance keeps running.
- Review authentication logs from the exposure window for logins that do not match known users or locations.
- Force a password reset and session revocation for privileged accounts if you find anything suspicious.
- Enable multi-factor authentication where your plan supports it, as defense in depth.
Why it matters
The root cause is CWE-287, improper authentication, but the trigger is a very ordinary coding slip. The password check calls bcrypt compare, which returns a Promise, and the login code did not await it. A Promise object is always truthy, so the check passed no matter what password arrived.
The advisory says this allows login as any user with a password set, using an arbitrary password, and could lead to account takeover for any user whose username is known or guessable. In a chat platform, that includes administrators.
This class of bug is hard to see in review, since the code reads as if it works and tests with a correct password pass. Linters that flag floating promises, and tests that try a wrong password on purpose, catch it early. The record does not mark the CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does enabling two-factor authentication make me safe?
It may reduce risk, but the advisory describes the bug in password validation within the service, and does not promise that second factors cover this path. Patch first and treat 2FA as an extra layer.
Sources
Last reviewed: 19 October 2026.
