CVE-2026-45689
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk22th percentile — higher than 22% of all known CVEs
Summary
An unauthenticated attacker can obtain a valid OAuth access token for any Rocket.Chat user by sending a single HTTP POST with MongoDB query operators to the /oauth/token endpoint. The OAuth2 server does not validate that grant parameters are strings, allowing substitution of values like {"$ne": null} and receiving an access token for the first matched user.
Risk Assessment
An attacker can steal an admin access token, granting full API access including app installation and server-side code execution. No account, credentials, or user interaction is required.
Recommendation
Immediately upgrade Rocket.Chat to one of the patched versions: 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, or 7.10.11.
Original NVD description (English source)
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, an unauthenticated network attacker obtains a valid Rocket.Chat OAuth access token for an arbitrary user by sending a single HTTP POST with MongoDB query operators to /oauth/token. The Rocket.Chat OAuth2 server does not validate that grant parameters are strings before forwarding them to findOne({...}) against the oauth_apps and oauth_access_tokens collections, so an attacker substitutes {"$ne": null} for client_id, client_secret, and refresh_token and receives a freshly minted {access_token, refresh_token} pair bound to whichever user's refresh token Mongo returned first. The resulting access token is a first-class bearer credential against the full /api/v1/* surface as that user. By iterating with $nin / $regex operators the attacker walks the entire oauth_access_tokens collection, collecting one fresh access token per user per request. If any matched token belongs to an admin, the stolen bearer gives full admin API access (including Apps-Engine app installation, i.e. server-side code execution). No account, credentials, userId, or prior interaction with the instance are required. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.

