CVE-2026-65645 in Rocket.Chat
Summary
by MITRE • 08/21/2026
Rocket.Chat in versions before 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6. 8.3.8, 8.2.8, 8.1.8, and 7.10.15, the Meteor DDP methods getThreadsList and getThreadMessages accept rid / tmid as raw, untyped parameters with no schema validation. A MongoDB operator object (e.g. {"$gt": "4"}) can be substituted for a string room-id or message-id. The authorization check resolves to a room the attacker already has access to, while the downstream data query fans out across all rooms - disclosing private thread parents and their full reply content to any low-privilege authenticated user.
The REST route chat.getThreadsList was patched in v5.0 (HackerOne report #1446767) by adding rid: {type:'string'} AJV validation. The equivalent DDP method was never given the same fix and remains exploitable
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in Rocket.Chat versions prior to 8.8.0, as well as specific earlier releases including 8.7.1 through 7.10.15, represents a critical server-side request forgery and insecure direct object reference flaw within the Meteor Distributed Data Protocol implementation. This issue stems from a lack of strict input validation on two core DDP methods: getThreadsList and getThreadMessages. These endpoints are designed to retrieve thread metadata and message content associated with specific rooms or threads, identified by parameters such as rid (room ID) and tmid (thread message ID). In the affected versions, these parameters are accepted as raw, untyped strings without any schema validation or type coercion mechanisms in place at the server side. This architectural oversight allows an attacker to inject MongoDB query operators directly into these parameter fields rather than providing standard alphanumeric identifiers for rooms or messages.
The technical exploitation of this vulnerability relies on the ability to substitute a standard string identifier with a MongoDB operator object, such as {"$gt": "4"}. When the server processes this malformed input, it does not reject the request due to type mismatch but instead passes the operator directly into the underlying database query logic. This behavior creates an opportunity for NoSQL injection attacks where the attacker can manipulate the query conditions to bypass intended access controls or retrieve unintended data sets. The authorization check performed by Rocket.Chat typically verifies if the authenticated user has permission to view a specific room based on the provided rid parameter. However, because the input is treated as a MongoDB operator rather than a literal string ID, the authorization logic may resolve against a different condition or default state that grants access, effectively bypassing the granular permissions intended for private threads and rooms.
The operational impact of this vulnerability is severe, leading to unauthorized disclosure of sensitive communication data. By exploiting the unvalidated input in getThreadsList and getThreadMessages, any low-privilege authenticated user can fan out queries across all accessible or even inaccessible rooms depending on how the MongoDB operator interacts with the database index and query planner. This results in the exposure of private thread parents and their full reply content to users who should not have access to them. The attacker does not need elevated privileges; standard authentication is sufficient to trigger this data exfiltration, violating the principle of least privilege and compromising the confidentiality guarantees expected by enterprise teams using Rocket.Chat for secure communications. This flaw undermines trust in the platform's ability to isolate private conversations from unauthorized viewers.
This vulnerability can be categorized under CWE-94 Improper Control of Generation of Code (Code Injection) specifically NoSQL injection, as well as CWE-285 Improper Authorization due to the failure to enforce access controls on sensitive data objects. In terms of MITRE ATT&CK mapping, this aligns with T1078 Valid Accounts and potentially T1005 Data from Local System if combined with other exploits, but primarily represents a mechanism for unauthorized data retrieval through API manipulation. It is notable that the REST API endpoint chat.getThreadsList was previously patched in version 5.0 via HackerOne report #1446767 by implementing strict AJV validation requiring rid to be of type string. However, this security fix was not applied consistently across all interfaces, leaving the DDP method vulnerable due to a lack of code parity between REST and WebSocket-based communication channels in Rocket.Chat's architecture.
Mitigation for this vulnerability requires immediate upgrading to version 8.8.0 or later, where the input validation logic has been corrected to enforce strict typing on rid and tmid parameters within the Meteor DDP methods. For organizations unable to upgrade immediately due to compatibility constraints, network-level controls such as Web Application Firewalls may offer limited protection by inspecting JSON payloads for MongoDB operator syntax patterns like $gt or $lt in API requests, though this is not a definitive solution given the complexity of legitimate query structures. Developers should also audit other DDP methods that accept object IDs to ensure consistent application of schema validation using tools like AJV or similar strict typing frameworks across all entry points. Regular security audits focusing on input validation parity between different protocol implementations are essential to prevent similar discrepancies from arising in future releases, ensuring that no single interface becomes a weak link in the overall security posture.