Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-10T22:17:10.957Z",
  "pubdate": "2026-08-10T22:17:10.957Z",
  "executiveSummary": "An authorization bypass vulnerability exists in the Rocket.Chat communications platform, specifically within the channels.convertToTeam REST endpoint. The vulnerability allows an authenticated registered user possessing the create-team permission to convert an unrelated public channel into a team by supplying the channelName parameter instead of the required channelId. This occurs because proper permission validation, specifically checking for the edit-room permission, is only enforced when channelId is supplied, failing to validate authorization correctly when channelName is used. The impact of this security flaw includes unauthorized modification and structural conversion of public chat channels by lower-privileged users, leading to a compromise in channel integrity and access control boundaries. The affected systems comprise Rocket.Chat 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. Exploitation requires authenticated access to the platform, possession of the specific create-team capability, and network connectivity to the REST API endpoints. Risk implications involve unauthorized administrative actions over arbitrary public communication structures within the deployment.",
  "technicalDetails": "The vulnerability resides within the REST API endpoint handling channel-to-team conversions in Rocket.Chat, specifically utilizing the channels.convertToTeam function. The root cause of the vulnerability is an incomplete authorization check and improper input parameter handling logic within the endpoint controller. When a client initiates a request to convert a channel, the backend application logic is designed to verify whether the executing user possesses the necessary administrative or moderation rights over the targeted resource, denoted by checking the edit-room permission.\nHowever, the application conditionally validates the edit-room permission based on the presence of the channelId parameter in the incoming HTTP request body. If an attacker supplies the channelName parameter instead of channelId, the validation routine for the edit-room permission is bypassed entirely. The attacker must still be an authenticated registered user and must possess the create-team permission, which acts as the baseline authentication and capability requirement to invoke the conversion functionality. Because the backend fails to validate whether the user has edit permissions specifically for the channel referenced by its name, an improper authorization check is committed.\nThe attack flow proceeds as follows: First, the authenticated attacker identifies a public channel they do not own or manage, noting its channelName. Second, the attacker crafts a malicious HTTP POST request targeting the channels.convertToTeam REST endpoint. Third, instead of populating the request payload with the standard channelId identifier, the attacker injects the target channelName parameter. Fourth, the server processes the request, validates that the attacker possesses the generic create-team permission, but omits the critical edit-room permission validation due to the absence of the channelId parameter. Finally, the application successfully executes the conversion logic, altering the structural state of the unrelated public channel into a team without the requisite authorization constraints being satisfied. This results in an arbitrary state change of communication channels across the platform instance."
}