Rocketchat

Don't miss out!

Thousands of developers use stack.watch to stay informed.
Get an email whenever new security vulnerabilities are reported in any Rocketchat product.

RSS Feeds for Rocketchat security vulnerabilities

Create a CVE RSS feed including security vulnerabilities found in Rocketchat products with stack.watch. Just hit watch, then grab your custom RSS feed url.

Products by Rocketchat Sorted by Most Security Vulnerabilities since 2018

Rocketchat Rocket Chat79 vulnerabilities

Rocketchat Livechat1 vulnerability

By the Year

In 2026 there have been 29 vulnerabilities in Rocketchat with an average score of 6.9 out of ten. Last year, in 2025 Rocketchat had 1 security vulnerability published. That is, 28 more vulnerabilities have already been reported in 2026 as compared to last year. Last year, the average CVE base score was greater by 0.57

Year	Vulnerabilities	Average Score
2026	29	6.93
2025	1	7.50
2024	6	6.60
2023	10	6.64
2022	18	5.71
2021	10	7.50
2020	2	7.95
2019	1	0.00
2018	2	0.00

It may take a day or so for new Rocketchat vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.

Recent Rocketchat Security Vulnerabilities

CVE	Date	Vulnerability	Products
CVE-2026-65644	Aug 21, 2026	Rocket.Chat <8.8.0 REST API XSS via unsanitized visitor name 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
CVE-2026-65645	Aug 21, 2026	Thread Data Disclosure via unvalidated rid/ tmid in Rocket.Chat <=8.8.0 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, the Meteor DDP methods getThreadsList and getThreadMessages accept rid / tmid as raw, untyped parameters with no schema validation. A MongoDB operator object (e.g. {"$gt": "4"}) can be substituted for a string room-id or message-id. The authorization check resolves to a room the attacker already has access to, while the downstream data query fans out across all rooms - disclosing private thread parents and their full reply content to any low-privilege authenticated user. The REST route chat.getThreadsList was patched in v5.0 (HackerOne report #1446767) by adding rid: {type:'string'} AJV validation. The equivalent DDP method was never given the same fix and remains exploitable	Rocket Chat
CVE-2026-72919	Aug 10, 2026	Auth user can convert channel to team via channels.convertToTeam (before 8.6.1) 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.	Rocket Chat
CVE-2026-72918	Aug 10, 2026	Rocket.Chat WS stream-notify-user Arbitrary Notification Injection (8.6.1) 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 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. 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.	Rocket Chat
CVE-2026-56845	Aug 04, 2026	Unauth LFI via /custom-sounds/ path traversal in FileSystem storage An unauthenticated path traversal (LFI) vulnerability exists under /custom-sounds/ when CustomSounds storage is configured to FileSystem. By including ../ sequences in the request path, an attacker can read arbitrary files outside the base directory.	Rocket Chat
CVE-2026-58066	Jul 30, 2026	Rocket.Chat SAML SSO XML Signature Bypass in v 8.7.0,8.6.1,8.5.2,8.4.5,8.3.7,8.2.7,8.1.7,8.0.8,7.10. 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
CVE-2026-55762	Jun 24, 2026	Rocket.Chat Auth Bypass via /api/v1/fingerprint (8.5.1) Rocket.Chat is an open-source, secure, fully customizable communications platform. 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 REST endpoint enforces authentication (authRequired: true) but performs no authorization check. Any authenticated user including a standard user role account can call this endpoint with {"setDeploymentAs": "new-workspace"} to permanently deregister the workspace from Rocket.Chat Cloud. This wipes all cloud credentials, removes the workspace license, breaks push notifications for all users, and requires manual re-registration to recover. This vulnerability is fixed in 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13.	Rocket Chat
CVE-2026-55759	Jun 24, 2026	Apple Sign-In JWT Claims Bypass in Rocket.Chat <8.5.1 (Replays Allowed) Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13, Rocket.Chat's Apple Sign-In handler verifies JWT signatures but skips claims validation. Any Apple-signed JWT with a non-empty iss is accepted regardless of aud, exp, nbf, or nonce. An attacker who obtains a target user's Apple identity token (from server logs, an intercepted sign-in flow, or another application sharing the same Apple developer team) can replay it to authenticate as that user, with no expiration on the replay window. This vulnerability is fixed in 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13.	Rocket Chat
CVE-2026-55666	Jun 24, 2026	CVE-2026-55666 Rocket.Chat <8.5.1 Apple OAuth JWT email bypass in loginHandler Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13, in apps/meteor/app/apple/server/loginHandler.ts, handleIdentityToken parses a JWT issued by Apple during the OAuth flow. The try block checks for an email parameter. If the JWT does not contain an email address, the application falls back to accepting an arbitrary email value supplied directly in the request. Attackers are able to forge Apple JWTs that do not contain an email address and leverage this vulnerability to carry out account takeover attacks. This vulnerability is fixed in 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13.	Rocket Chat
CVE-2026-49278	Jun 24, 2026	Rocket.Chat visitor.info token leakage (before 8.5.0) Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 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, in the visitors.info endpoint, https://developer.rocket.chat/apidocs/get-visitor-information-by-id-1, token is returned in the response. It looks like there's no use case for the token to be present in the response and it would be a good security practice to remove it altogether. This vulnerability is fixed in 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.	Rocket Chat