CVE-2026-45689: CWE-943: Improper Neutralization of Special Elements in Data Query Logic in RocketChat Rocket.Chat
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.
AI Analysis
Technical Summary
Rocket.Chat versions before 7.10.11, 7.13.7, 8.0.5, 8.1.4, 8.2.3, 8.3.3, 8.4.1, and 8.5.0 contain a vulnerability where the OAuth2 server does not validate that grant parameters are strings before using them in MongoDB queries. An attacker can send specially crafted HTTP POST requests with MongoDB query operators such as {$ne: null} to the /oauth/token endpoint. This causes the server to return a valid access token and refresh token pair for an arbitrary user by matching the first token found in the database. By iterating with other MongoDB operators, the attacker can enumerate tokens for all users, including admins, thereby gaining full bearer token access to the API and potentially executing server-side code via admin privileges. No authentication or prior knowledge is required. The vulnerability is identified as CWE-943 (Improper Neutralization of Special Elements in Data Query Logic).
Potential Impact
An unauthenticated remote attacker can obtain valid OAuth access tokens for any user, including administrators, without credentials or prior interaction. This grants full API access as the compromised user, including administrative capabilities such as installing Apps-Engine applications, which can lead to server-side code execution. The vulnerability severely compromises confidentiality and integrity of the Rocket.Chat instance but does not affect availability.
Mitigation Recommendations
This vulnerability is fixed in Rocket.Chat versions 7.10.11, 7.13.7, 8.0.5, 8.1.4, 8.2.3, 8.3.3, 8.4.1, and 8.5.0. Users should upgrade to one of these versions or later to remediate the issue. Patch status is not explicitly stated beyond these fixed versions, so check the vendor advisory for the latest remediation guidance. No temporary or alternative mitigations are provided in the available data.
CVE-2026-45689: CWE-943: Improper Neutralization of Special Elements in Data Query Logic in RocketChat Rocket.Chat
Description
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.
CVSS v3.1
Score 9.1critical
Affected software
pkg:github/rocketchat/Rocket.ChatRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Rocket.Chat versions before 7.10.11, 7.13.7, 8.0.5, 8.1.4, 8.2.3, 8.3.3, 8.4.1, and 8.5.0 contain a vulnerability where the OAuth2 server does not validate that grant parameters are strings before using them in MongoDB queries. An attacker can send specially crafted HTTP POST requests with MongoDB query operators such as {$ne: null} to the /oauth/token endpoint. This causes the server to return a valid access token and refresh token pair for an arbitrary user by matching the first token found in the database. By iterating with other MongoDB operators, the attacker can enumerate tokens for all users, including admins, thereby gaining full bearer token access to the API and potentially executing server-side code via admin privileges. No authentication or prior knowledge is required. The vulnerability is identified as CWE-943 (Improper Neutralization of Special Elements in Data Query Logic).
Potential Impact
An unauthenticated remote attacker can obtain valid OAuth access tokens for any user, including administrators, without credentials or prior interaction. This grants full API access as the compromised user, including administrative capabilities such as installing Apps-Engine applications, which can lead to server-side code execution. The vulnerability severely compromises confidentiality and integrity of the Rocket.Chat instance but does not affect availability.
Mitigation Recommendations
This vulnerability is fixed in Rocket.Chat versions 7.10.11, 7.13.7, 8.0.5, 8.1.4, 8.2.3, 8.3.3, 8.4.1, and 8.5.0. Users should upgrade to one of these versions or later to remediate the issue. Patch status is not explicitly stated beyond these fixed versions, so check the vendor advisory for the latest remediation guidance. No temporary or alternative mitigations are provided in the available data.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-05-13T04:38:01.164Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a3c4ce14853345fc1df8cf2
Added to database: 06/24/2026, 21:32:17 UTC
Last enriched: 07/01/2026, 22:34:34 UTC
Last updated: 08/08/2026, 12:41:10 UTC
Views: 66
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.