Vulnerabilities

Rocket.Chat in versions before 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 has a REST API endpoint POST /api/v1/livechat/visitor that accepts an unauthenticated, unsanitized name field for Livechat visitors. This name is stored raw and later rendered via dangerouslySetInnerHTML in the Omnichannel Queue side panel (InquireSidePanelItem.tsx), injecting a real, clickable HTML link - pointing to any attacker-controlled domain, with arbitrary social-engineering text - into the DOM of any agent viewing the queue.

Rocket.Chat's SAML SSO 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 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.

Rocket.Chat versions <8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, 7.13.9, 7.10.13 has an access control vulnerability in Livechat files. Protected file downloads at /file-upload/:fileId/:name authorize livechat access using rc_room_type=l with rc_rid+rc_token, but the authorization path does not verify that rc_rid matches the requested file's rid. Furthermore, :fileId is predictable via sequential MongoDB IDs, and :name can be anything, allowing unauthenticated discovery of all uploaded files.

In versions <8.4.0, <8.3.2, <8.2.2, <8.1.3, <8.0.4, <7.13.6, <7.12.7, <7.11.7, and <7.10.10, the endpoints /api/apps/logs and /api/apps/:id/logs have a typo in the required permission check, allowing authenticated users without the proper permissions to read apps-engine logs.

In Rocket.Chat <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.

An open redirect vulnerability in Rocket.Chat versions prior to 8.4.0 allows users to be redirected to arbitrary URLs by manipulating parameters within a SAML endpoint.

Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to versions 7.8.6, 7.9.8, 7.10.7, 7.11.4, 7.12.4, 7.13.3, and 8.0.0, a critical authentication bypass vulnerability exists in Rocket.Chat's account service used in the ddp-streamer micro service that allows an attacker to log in to the service as any user with a password set, using any arbitrary password. The vulnerability stems from a missing await keyword when calling an asynchronous password validation function, causing a Promise object (which is always truthy) to be evaluated instead of the actual boolean validation result. This may lead to account takeover of any user whose username is known or guessable. This issue has been patched in versions 7.8.6, 7.9.8, 7.10.7, 7.11.4, 7.12.4, 7.13.3, and 8.0.0.

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.

rocket.chat Incorrect Authorization Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of rocket.chat. Authentication is not required to exploit this vulnerability. The specific flaw exists within the web service, which listens on TCP port 3000 by default. The issue results from incorrect authorization. An attacker can leverage this vulnerability to disclose information in the context of the application. Was ZDI-CAN-26517.

A vulnerability, which was classified as problematic, has been found in RocketChat up to 7.6.1. This issue affects the function parseMessage of the file /apps/meteor/app/irc/server/servers/RFC2813/parseMessage.js. The manipulation of the argument line leads to inefficient regular expression complexity. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.

Rocket.Chat 6.12.0, 6.11.2, 6.10.5, 6.9.6, 6.8.6, 6.7.8, and earlier is vulnerable to denial of service (DoS). Attackers who craft messages with specific characters may crash the workspace due to an issue in the message parser.

The Electron desktop application of Rocket.Chat through 6.3.4 allows stored XSS via links in an uploaded file, related to failure to use a separate browser upon encountering third-party external actions from PDF documents.

A Server-Side Request Forgery (SSRF) affects Rocket.Chat's Twilio webhook endpoint before version 6.10.1.

A vulnerability has been identified where a maliciously crafted message containing a specific chain of characters can cause the chat to enter a hot loop on one of the processes, consuming ~120% CPU and rendering the service unresponsive.

A security vulnerability has been discovered in the implementation of 2FA on the rocket.chat platform, where other active sessions are not invalidated upon activating 2FA. This could potentially allow an attacker to maintain access to a compromised account even after 2FA is enabled.

An improper access control vulnerability exists prior to v6 that could allow an attacker to break the E2E encryption of a chat room by a user changing the group key of a chat 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.

A command injection vulnerability exists in Rocket.Chat-Desktop <3.8.14 that could allow an attacker to pass a malicious url of openInternalVideoChatWindow to shell.openExternal(), which may lead to remote code execution (internalVideoChatWindow.ts#L17). To exploit the vulnerability, the internal video chat window must be disabled or a Mac App Store build must be used (internalVideoChatWindow.ts#L14). The vulnerability may be exploited by an XSS attack because the function openInternalVideoChatWindow is exposed in the Rocket.Chat-Desktop-API.

A improper authentication vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 that allowed two factor authentication can be bypassed when telling the server to use CAS during login.

A blind self XSS vulnerability exists in RocketChat LiveChat <v1.9 that could allow an attacker to trick a victim pasting malicious code in their chat instance.

A link preview rendering issue in Rocket.Chat versions before 3.9 could lead to potential XSS attacks.

Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript. In Rocket.Chat before versions 3.11.3, 3.12.2, and 3.13 an issue with certain regular expressions could lead potentially to Denial of Service. This was fixed in versions 3.11.3, 3.12.2, and 3.13.

A sanitization vulnerability exists in Rocket.Chat server versions <3.13.2, <3.12.4, <3.11.4 that allowed queries to an endpoint which could result in a NoSQL injection, potentially leading to RCE.