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 lets any authenticated user 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 in Rocket.Chat's DDP layer, and it undermines the confidentiality that organizations deploying the 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 use in sensitive government and defense settings makes access control failures especially consequential.

Technical Information

Root Cause: Missing Authorization in the DDP Method

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

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.

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

The REST vs. DDP Inconsistency

The REST API endpoint for the same autoTranslate.translateMessage functionality had already been secured with a canAccessRoomAsync check in an earlier pull request (#40508). That security update missed the DDP method. As a result, REST calls to the translation endpoint were properly validated, and DDP calls to the same underlying functionality were not.

Applying a security fix to one interface without carrying it over to the parallel ones is a recurring risk in applications that expose the same operations through several API surfaces (REST, DDP, GraphQL).

Attack Flow

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

1. Get an authenticated DDP session. Any registered user account on the Rocket.Chat instance is enough. No admin or elevated permissions are needed.
2. Find 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 and supplies the target message _id in the IMessage object.
4. Read the response. The server processes the translation request and returns the translated content, which exposes the original message text whether or not the attacker belongs to the room.

This works against every room type in Rocket.Chat:

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

E2EE Bypass Implications

End-to-end encryption is meant to ensure that only the intended recipients can read a message, keeping it even from server administrators. The auto-translate feature, however, has to access decrypted content on the server in order to translate it. Because the DDP method had no room membership check, any authenticated user could use that server-side decryption path to read E2EE room content. This effectively negates the confidentiality 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. The primary attack vector is still a direct message ID reference, but this injection surface is further evidence that the original implementation did not validate its input.

Affected Systems and Versions

The vulnerability spans eight release branches, which indicates it has been in the codebase for a long time:

The span from 7.10.x through 8.5.x covers years of releases. A Rocket.Chat deployment running any version in these ranges is potentially vulnerable if the auto-translate feature is available. The feature does not need to be actively configured.

Vendor Security History

Rocket.Chat's 2026 security record shows a systemic pattern of vulnerabilities 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 day, March 6, 2026, which suggests they were found and patched as a coordinated batch after a deeper security review of the DDP layer. The GitHub Security Lab advisory for CVE-2026-28514 noted that the critical authentication bypass was in the account service used by 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, leaving each method's author to implement their own authorization checks. The REST API layer appears to have had more systematic security hardening. Until Rocket.Chat closes this gap with mandatory authorization middleware for all DDP methods, similar vulnerabilities are likely to keep surfacing.

For CVE-2026-32995 itself, researcher deprrous submitted the HackerOne report on May 14, 2026. Rocket.Chat triaged it, raised the severity from Medium (6.5) to High (7.5), and merged the fix the same day. Public disclosure followed on May 25, 2026. An 11-day turnaround is reasonable, though no bounty was awarded for the report.

Potential Attack Chain with Prior CVEs

CVE-2026-28514 (authentication bypass allowing login with any password) and CVE-2026-32995 (message IDOR) together form a concerning theoretical chain. On an unpatched instance, an unauthenticated attacker could first bypass authentication with CVE-2026-28514, then use CVE-2026-32995 to read private messages across the entire server. Organizations running older, unpatched Rocket.Chat versions may be exposed to both vulnerabilities at once.

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