Rocket.Chat CVE-2026-32995: Brief Summary of the AutoTranslate IDOR That Exposes Private Messages Across All Room Types

Introduction

A missing authorization check in Rocket.Chat's auto-translate feature allows any authenticated user to read the contents of any message on the server, including messages in private channels, direct messages, and end-to-end encrypted rooms. CVE-2026-32995, scored at CVSS 7.5 (High), is the latest in a string of 2026 vulnerabilities targeting Rocket.Chat's DDP layer, and it directly undermines the confidentiality guarantees that organizations deploying this platform rely on.

Rocket.Chat is an open source team communication platform marketed as "The Secure CommsOS for mission-critical operations." It serves commercial, government, and defense customers, with deployment options that include air-gapped environments and government-owned servers. The platform competes with Slack and Microsoft Teams in the self-hosted messaging space, and its adoption in sensitive government and defense contexts makes access control failures especially consequential.

Technical Information

Root Cause: Missing Authorization in the DDP Method

The vulnerability exists in the Meteor DDP method autoTranslate.translateMessage, implemented in the file apps/meteor/app/autotranslate/server/methods/translateMessage.ts. The method accepts a client-supplied IMessage object and passes it directly to the internal translateMessage() function. Two critical authorization checks are absent:

1. The method does not verify that Meteor.userId() returns a valid authenticated user.
2. The method does not confirm that the calling user is a member of the room containing the target message.

This is classified under CWE-284 (Improper Access Control) and constitutes a textbook Insecure Direct Object Reference (IDOR) vulnerability.

The REST vs. DDP Inconsistency

What makes this vulnerability particularly instructive is that the parallel REST API endpoint for the same autoTranslate.translateMessage functionality had already been secured with a canAccessRoomAsync check in a prior pull request (#40508). The DDP method was simply missed during that security update. This created a split security posture: REST calls to the translation endpoint were properly validated, while DDP calls to the same underlying functionality were not.

This pattern, where security fixes are applied to one interface but not propagated to parallel interfaces, is a recurring risk in applications that expose multiple API surfaces (REST, DDP, GraphQL) for the same operations.

Attack Flow

Exploitation is straightforward and requires no special privileges or complex attack chains:

1. Obtain an authenticated DDP session. Any registered user account on the Rocket.Chat instance is sufficient. No admin or elevated permissions are needed.
2. Identify a target message ID. The attacker needs the _id of a message in a room they do not have access to. Message IDs may be enumerable or discoverable through other means.
3. Call the DDP method. The attacker invokes autoTranslate.translateMessage, supplying the target message _id in the IMessage object.
4. Receive the message content. The server processes the translation request and returns the translated content, which inherently exposes the original message text, regardless of whether the attacker belongs to the room.

This works against all room types in Rocket.Chat:

• Public channels
• Private channels (where membership is restricted)
• Direct messages between users
• End-to-end encrypted (E2EE) rooms

E2EE Bypass Implications

The impact on E2EE rooms deserves special attention. End-to-end encryption is designed to ensure that only intended recipients can read message content, even protecting against server administrators. However, the auto-translate feature necessarily accesses decrypted content server-side in order to perform translation. Because the DDP method lacked room membership verification, any authenticated user could leverage this server-side decryption pathway to read E2EE room content. This effectively negates the confidentiality guarantees that E2EE is supposed to provide.

NoSQL Injection Surface

The end-to-end tests added in the fix PR also confirm that NoSQL operator injection attempts (such as supplying {$gt: ''} as a messageId) were possible against the unpatched method. While the primary attack vector is direct message ID reference, this additional injection surface further illustrates the lack of input validation in the original implementation.

Affected Systems and Versions

The vulnerability spans eight release branches, indicating it has been present in the codebase for a significant period:

The broad span from 7.10.x through 8.5.x covers years of releases. Any Rocket.Chat deployment running a version within these ranges that has the auto-translate feature available (it does not need to be actively configured) is potentially vulnerable.

Vendor Security History

Rocket.Chat's 2026 security record reveals a systemic pattern of vulnerabilities concentrated in the DDP and ddp-streamer subsystem. Five of the six CVEs published for Rocket.Chat in 2026 directly involve this layer:

Three of these (CVE-2026-28514, CVE-2026-28515, CVE-2026-30833) were published on the same date (March 6, 2026), suggesting they were discovered and patched as a coordinated batch following deeper security review of the DDP layer. The GitHub Security Lab advisory for CVE-2026-28514 noted that the critical authentication bypass existed in the account service used in the ddp-streamer microservice.

This concentration of vulnerabilities points to an architectural concern: the DDP layer appears to have been built without a consistent security middleware framework, relying instead on individual method authors to implement their own authorization checks. The REST API layer, by contrast, appears to have received more systematic security hardening. Until this architectural gap is addressed with a mandatory authorization middleware for all DDP methods, similar vulnerabilities are likely to continue surfacing.

Regarding disclosure handling for CVE-2026-32995 specifically: researcher deprrous submitted the HackerOne report on May 14, 2026, and Rocket.Chat triaged it, escalated the severity from Medium (6.5) to High (7.5), and merged the fix on the same day. Public disclosure followed on May 25, 2026, an 11-day turnaround that is reasonable. However, no bounty was awarded for this report.

Potential Attack Chain with Prior CVEs

The combination of CVE-2026-28514 (authentication bypass allowing login with any password) and CVE-2026-32995 (message IDOR) presents a concerning theoretical chain: an unauthenticated attacker could first bypass authentication via CVE-2026-28514 on an unpatched instance, then leverage CVE-2026-32995 to read private messages across the entire server. Organizations running older, unpatched Rocket.Chat versions may be exposed to both vulnerabilities simultaneously.

References

• NVD: CVE-2026-32995
• HackerOne Report #3734326: Autotranslate DDP IDOR
• GitHub PR #40528: Fix for translateMessage Meteor method
• Rocket.Chat Security Fixes and Advisories
• Rocket.Chat Auto-Translate Documentation
• GHSA-w6vw-mrgv-69vf: Authentication bypass via ddp-streamer (CVE-2026-28514)
• GHSA-7qr6-q62g-hm63: 2FA bypass via ddp-streamer (CVE-2026-28515)
• GHSA-hgq6-9jg2-wf3f: NoSQL injection in ddp-streamer (CVE-2026-30833)
• GitHub Security Lab Advisory: GHSL-2026-004/005 Rocket.Chat
• SentinelOne: CVE-2026-23477 Rocket.Chat Information Disclosure
• SentinelOne: CVE-2026-22560 Rocket.Chat Open Redirect
• Rocket.Chat for Government