CVE-2026-72919 in Rocket.Chat
Summary
by MITRE • 08/11/2026
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1, the channels.convertToTeam REST endpoint allows an authenticated registered user with the create-team permission to convert an unrelated public channel by supplying channelName instead of channelId because the edit-room permission is checked only for channelId. This issue is fixed in versions 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/11/2026
The vulnerability in Rocket.Chat affects the channels.convertToTeam REST endpoint, which allows authenticated users to convert public channels into teams through a flawed permission checking mechanism. This security flaw exists in versions prior to 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1, creating a significant access control issue that could enable unauthorized team conversions. The vulnerability stems from the inconsistent validation of permissions between channel identifiers, where the system properly checks for edit-room permissions when using channelId but fails to perform the same validation when channelName is provided instead.
The technical implementation flaw manifests in how the system processes user requests for converting channels to teams. When a user supplies channelName rather than channelId, the system bypasses the proper permission verification that should occur before allowing the conversion operation. This creates a path where an authenticated registered user with create-team permissions can manipulate the endpoint to convert public channels they do not actually have edit access to, essentially circumventing the intended security controls. The flaw represents a classic case of incomplete input validation and inconsistent access control enforcement.
From an operational impact perspective, this vulnerability allows attackers to potentially convert public channels into teams without proper authorization, which could lead to unauthorized data organization and potential information disclosure. The ability to convert unrelated public channels into teams creates opportunities for malicious actors to reorganize communication structures in ways that might obscure legitimate discussions or create confusion within the platform. This could also enable privilege escalation scenarios where users gain unintended administrative capabilities over team structures they should not control.
The vulnerability aligns with CWE-284 Access Control Issues, specifically targeting improper access control mechanisms that allow unauthorized operations through alternative input methods. From an ATT&CK framework perspective, this represents a privilege escalation technique through API manipulation and access control bypass. The issue demonstrates poor input sanitization and inconsistent validation patterns that could be exploited by both malicious insiders and external attackers who have obtained legitimate user credentials.
Mitigation strategies should focus on ensuring consistent permission checking regardless of how channel identification is provided to the endpoint. Organizations should immediately update to the patched versions 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2, and 8.6.1 where the fix ensures that edit-room permissions are validated consistently for both channelId and channelName parameters. Additional defensive measures include implementing stricter API request validation, monitoring for unusual conversion patterns, and ensuring proper least-privilege access controls are enforced throughout the platform's permission architecture. Security teams should also conduct comprehensive audits of similar endpoints to identify other potential access control bypass opportunities that may exist in the system's REST API implementations.