Rocket.Chat Server version 0.59 and prior is vulnerable to a NoSQL injection leading to administrator account takeover

An XSS issue was discovered in packages/rocketchat-mentions/Mentions.js in Rocket.Chat before 0.65. The real name of a username is displayed unescaped when the user is mentioned (using the @ symbol) in a channel or private chat. Consequently, it is possible to exfiltrate the secret token of every user and also admins in the channel.

A reflected XSS issue was discovered in the registration form in Rocket.Chat before 0.66. When one creates an account, the next step will ask for a username. This field will not save HTML control characters but an error will be displayed that shows the attempted username unescaped via packages/rocketchat-ui-login/client/username/username.js in packages/rocketchat-ui-login/client/username/username.html.

Rocket.Chat before 2.1.0 allows XSS via a URL on a ![title] line.

Rocket.Chat through 3.4.2 allows XSS where an attacker can send a specially crafted message to a channel or in a direct message to the client which results in remote code execution on the client side.

The Rocket.Chat desktop application 2.17.11 opens external links without user interaction.

An email address enumeration vulnerability exists in the password reset function of Rocket.Chat through 3.9.1.

Rocket.Chat before 0.74.4, 1.x before 1.3.4, 2.x before 2.4.13, 3.x before 3.7.3, 3.8.x before 3.8.3, and 3.9.x before 3.9.1 mishandles SAML login.

The `specializedRendering` function in Rocket.Chat server before 3.9.2 allows a cross-site scripting (XSS) vulnerability by way of the `value` parameter.

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

Rocket.Chat server before 3.9.0 is vulnerable to a self cross-site scripting (XSS) vulnerability via the drag & drop functionality in message boxes.

Rocket.Chat before 3.11, 3.10.5, 3.9.7, 3.8.8 is vulnerable to persistent cross-site scripting (XSS) using nested markdown tags allowing a remote attacker to inject arbitrary JavaScript in a message. This flaw leads to arbitrary file read and RCE on Rocket.Chat desktop app.

An information disclosure vulnerability exists in the Rocket.Chat server fixed v3.13, v3.12.2 & v3.11.3 that allowed email addresses to be disclosed by enumeration and validation checks.

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.

A improper input sanitization vulnerability exists in Rocket.Chat server 3.11, 3.12 & 3.13 that could lead to unauthenticated NoSQL injection, resulting potentially in RCE.

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 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.

An improper authentication vulnerability exists in Rocket.Chat Mobile App <4.14.1.22788 that allowed an attacker with physical access to a mobile device to bypass local authentication (PIN code).

A SQL injection vulnerability exists in Rocket.Chat <v3.18.6, <v4.4.4 and <v4.7.3 which can allow an attacker to retrieve a reset password token through or a 2fa secret.

A cleartext storage of sensitive information exists in Rocket.Chat <v4.6.4 due to Oauth token being leaked in plaintext in Rocket.chat logs.

An information disclosure vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 due to the actionLinkHandler method was found to allow Message ID Enumeration with Regex MongoDB queries.

An information disclosure vulnerability exists in Rocket.Chat <v4.7.5 which allowed the "users.list" REST endpoint gets a query parameter from JSON and runs Users.find(queryFromClientSide). This means virtually any authenticated user can access any data (except password hashes) of any user authenticated.

An information disclosure vulnerability exists in Rocket.Chat <v5 due to the getUserMentionsByChannel meteor server method discloses messages from private channels and direct messages regardless of the users access permission to the room.

An improper access control vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 due to input data in the getUsersOfRoom Meteor server method is not type validated, so that MongoDB query operator objects are accepted by the server, so that instead of a matching rid String a$regex query can be executed, bypassing the room access permission check for every but the first matching room.

A cleartext transmission of sensitive information exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 relating to Oauth tokens by having the permission "view-full-other-user-info", this could cause an oauth token leak in the product.

An information disclosure vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 since the getReadReceipts Meteor server method does not properly filter user inputs that are passed to MongoDB queries, allowing $regex queries to enumerate arbitrary Message IDs.

A information disclosure vulnerability exists in Rockert.Chat <v5 due to /api/v1/chat.getThreadsList lack of sanitization of user inputs and can therefore leak private thread messages to unauthorized users via Mongo DB injection.

A NoSQL-Injection information disclosure vulnerability vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 in the getS3FileUrl Meteor server method that can disclose arbitrary file upload URLs to users that should not be able to access.

A information disclosure vulnerability exists in Rocket.chat <v5, <v4.8.2 and <v4.7.5 where the lack of ACL checks in the getRoomRoles Meteor method leak channel members with special roles to unauthorized clients.

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 information disclosure vulnerability exists in Rocket.Chat <v5 where the getUserMentionsByChannel meteor server method discloses messages from private channels and direct messages regardless of the users access permission to the room.

A privilege escalation vulnerability exists in Rocket.chat <v5 which made it possible to elevate privileges for any authenticated user to view Direct messages without appropriate permissions.

A cross-site scripting vulnerability exists in Rocket.chat <v5 due to style injection in the complete chat window, an adversary is able to manipulate not only the style of it, but will also be able to block functionality as well as hijacking the content of targeted users. Hence the payloads are stored in messages, it is a persistent attack vector, which will trigger as soon as the message gets viewed.

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.

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 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.

A vulnerability has been discovered in Rocket.Chat, where editing messages can change the original timestamp, causing the UI to display messages in an incorrect order.

A vulnerability has been discovered in Rocket.Chat, where messages can be hidden regardless of the Message_KeepHistory or Message_ShowDeletedStatus server configuration. This allows users to bypass the intended message deletion behavior, hiding messages and deletion notices.

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 message in the target room.

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 vulnerability has been identified in Rocket.Chat, where the ACL checks in the Slash Command /mute occur after checking whether a user is a member of a given channel, leaking private channel members to unauthorized users. This allows authenticated users to enumerate whether a username is a member of a channel that they do not have access to.

A vulnerability has been discovered in Rocket.Chat where a markdown parsing issue in the "Search Messages" feature allows the insertion of malicious tags. This can be exploited on servers with content security policy disabled possible leading to some issues attacks like account takeover.

A NoSQL injection vulnerability has been identified in the listEmojiCustom method call within Rocket.Chat. This can be exploited by unauthenticated users when there is at least one custom emoji uploaded to the Rocket.Chat instance. The vulnerability causes a delay in the server response, with the potential for limited impact.

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 DOM-based Cross-site Scripting (XSS). Attackers may be able to abuse the UpdateOTRAck method to forge a message that contains an XSS payload.

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.

Rocket.Chat 6.12.0, 6.11.2, 6.10.5, 6.9.6, 6.8.6, 6.7.8, and earlier allows stored XSS in the description and release notes of the marketplace and private apps.

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 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.

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 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.

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.

Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to versions 7.10.8, 7.11.5, 7.12.5, 7.13.4, 8.0.2, 8.1.1, and 8.2.0, authentication vulnerabilities exist in Rocket.Chat's enterprise DDP Streamer service. The Account.login method exposed through the DDP Streamer does not enforce Two-Factor Authentication (2FA) or validate user account status (deactivated users can still login), despite these checks being mandatory in the standard Meteor login flow. This issue has been patched in versions 7.10.8, 7.11.5, 7.12.5, 7.13.4, 8.0.2, 8.1.1, and 8.2.0.

Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to versions 7.10.8, 7.11.5, 7.12.5, 7.13.4, 8.0.2, 8.1.1, and 8.2.0, a NoSQL injection vulnerability exists in Rocket.Chat's account service used in the ddp-streamer micro service that allows unauthenticated attackers to manipulate MongoDB queries during authentication. The vulnerability is located in the username-based login flow where user-supplied input is directly embedded into a MongoDB query selector without validation. An attacker can inject MongoDB operator expressions (e.g., { $regex: '.*' }) in place of a username string, causing the database query to match unintended user records. This issue has been patched in versions 7.10.8, 7.11.5, 7.12.5, 7.13.4, 8.0.2, 8.1.1, and 8.2.0.