Rocket.Chat vulnerabilities

Rocket.Chat is an open-source, secure, fully customizable communications platform. In Rocket.Chat versions up to 6.12.0, the API endpoint GET /api/v1/oauth-apps.get is exposed to any authenticated user, regardless of their role or permissions. This endpoint returns an OAuth application, as long as the user knows its ID, including potentially sensitive fields such as client_id and client_secret. This vulnerability is fixed in 6.12.0.

In Rocket.Chat before versions 8.7.0, 8.6.1, 8.5.2, 8.4.5, 8.3.7, 8.2.7, 8.1.7, 8.0.8, and 7.10.14, SAML SSO verified XML signatures but did not bind the validated signature to samlp:Response / saml:Assertion. An attacker could submit a wrapped document carrying forged identity attributes alongside any valid signature made by the trusted IdP certificate, and log in as an arbitrary user.

In Rocket.Chat prior to versions 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13, in loginHandler.ts, handleIdentityToken parses a JWT from Apple during OAuth. If the JWT lacks an email, the app accepts an arbitrary email from the request, enabling account takeover.

Rocket.Chat versions below 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, 7.13.9, 7.10.13 have an access control vulnerability in Livechat files. The authorization process for downloading protected files does not verify that rc_rid matches the requested file, allowing unauthenticated discovery of all uploaded files.

In Rocket.Chat versions below 8.3.0, 8.2.1, 8.1.2, 8.0.3, 7.13.5, 7.12.6, 7.11.6, and 7.10.9, a NoSQL injection vulnerability can lead to account takeover of the first user with a generated token when an OAuth app is configured.

Rocket.Chat exposes the sendForgotPasswordEmail Meteor method without a DDP rate limit, allowing unauthenticated callers to invoke it repeatedly. The method is reachable over DDP and HTTP POST /api/v1/method.callAnon/sendForgotPasswordEmail, triggering password reset emails for any address matching an account. With no DDPRateLimiter rule, attackers can send unbounded volumes of reset mail and probe addresses at scale.

In Rocket.Chat before versions 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 DDP methods getThreadsList and getThreadMessages accept raw, untyped parameters. A MongoDB operator object can be substituted for a string room-id or message-id, leading to disclosure of private thread parents and their full reply content to any low-privilege authenticated user.

In Rocket.Chat before versions 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 REST API endpoint POST /api/v1/livechat/visitor accepts an unauthenticated, unsanitized name field. This name is stored raw and rendered via dangerouslySetInnerHTML, injecting a clickable HTML link into the DOM of any agent viewing the queue.

In Rocket.Chat prior to 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, the channels.convertToTeam REST endpoint allows an authenticated user with 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.

In Rocket.Chat prior to 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, the stream-notify-user stream in the WebSocket protocol allows an authenticated user to write arbitrary notification bodies because the sender is not checked, and the client-side UI can create an ephemeral fake message in another user's currently open chat.

In Rocket.Chat versions prior to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13, the POST /api/v1/fingerprint endpoint requires authentication but does not perform authorization checks. Any authenticated user could deregister the workspace from Rocket.Chat Cloud, leading to data loss and requiring manual re-registration.

Rocket.Chat prior to versions 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12 allowed users deactivated through users.deactivateIdle to continue using already-issued login tokens. A user marked inactive by an administrator could still access authenticated REST endpoints with the old token.

Rocket.Chat prior to version 8.5.0 does not verify the signature on LogoutRequest messages in SAML integration. An unauthorized attacker can craft a fake logout request, leading to the immediate termination of the victim's session.

Rocket.Chat versions <8.5.1, <8.4.4, <8.3.6, <8.2.6, <8.1.6, <8.0.7, <7.13.9, and <7.10.13 are vulnerable to unauthenticated file deletion. The deleteFileMessage method allows for the permanent deletion of any uploaded file by ID without requiring authentication.

The /api/v1/autotranslate.translateMessage endpoint in Rocket.Chat (versions before 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, 7.10.12) allows any authenticated user to retrieve the full content of any message from any room without access check.

Rocket.Chat contains an incorrect authorization vulnerability in its web service (default TCP port 3000) that allows remote attackers to disclose sensitive information without authentication.

An improper authorization vulnerability exists in Rocket.Chat < 6.0 that could allow a hacker to manipulate the rid parameter and change the updateMessage method that only checks whether the user is allowed to edit a message in the target room.

A prototype pollution vulnerability exists in Rocket.Chat server <5.2.0 that could allow an attacker to a RCE under the admin account. Any user can create their own server in your cloud and become an admin so this vulnerability could affect the cloud infrastructure. This attack vector also may increase the impact of XSS to RCE which is dangerous for self-hosted users as well.