Rocketchat

By the Year

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

Recent Rocketchat Security Vulnerabilities

CVE	Date	Vulnerability	Products
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
CVE-2026-49277	Jun 24, 2026	OAuth Tokens Not Revoked on User Deactivation in Rocket.Chat <8.5 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, Rocket.Chat does not revoke OAuth bearer or refresh tokens when a user is deactivated. A deactivated user can continue using an existing OAuth access token, and can also mint a fresh access token from an existing refresh token. 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
CVE-2026-45757	Jun 24, 2026	Rocket.Chat 8.5.0 Idle Deactivation Token Reuse 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, Rocket.Chat allows users deactivated through users.deactivateIdle to keep using already-issued login tokens. A user that an administrator has marked inactive for idleness can still access authenticated REST endpoints with the old token. 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
CVE-2026-46423	Jun 24, 2026	Rocket.Chat SAML Auth Bypass (Signature Validation Skipped) <8.5.0 Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, Rocket.Chat's SAML service provider implementation silently skips both SAML Response and Assertion signature validation when the configured IdP certificate field is empty. The verifySignatures routine performs an early return when serviceProviderOptions.cert is falsy, which is the default state of the setting. Because provider registration only gates on the SAML "enabled" toggle and not on the presence of a certificate, an administrator who enables SAML without pasting an IdP certificate obtains a fully wired, publicly reachable SAML login endpoint that accepts unsigned or attacker-supplied assertions. This is a default-configuration authentication-bypass class: the fail-open branch is reached with no misconfiguration beyond leaving a field at its shipped default. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.	Rocket Chat
CVE-2026-45689	Jun 24, 2026	Unauthenticated OAuth token hijack via MongoDB injection in Rocket.Chat <8.5.0 Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, an unauthenticated network attacker obtains a valid Rocket.Chat OAuth access token for an arbitrary user by sending a single HTTP POST with MongoDB query operators to /oauth/token. The Rocket.Chat OAuth2 server does not validate that grant parameters are strings before forwarding them to findOne({...}) against the oauth_apps and oauth_access_tokens collections, so an attacker substitutes {"$ne": null} for client_id, client_secret, and refresh_token and receives a freshly minted {access_token, refresh_token} pair bound to whichever user's refresh token Mongo returned first. The resulting access token is a first-class bearer credential against the full /api/v1/* surface as that user. By iterating with $nin / $regex operators the attacker walks the entire oauth_access_tokens collection, collecting one fresh access token per user per request. If any matched token belongs to an admin, the stolen bearer gives full admin API access (including Apps-Engine app installation, i.e. server-side code execution). No account, credentials, userId, or prior interaction with the instance are required. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.	Rocket Chat
CVE-2026-45688	Jun 24, 2026	NoSQLi via CAS login, Auth token theft in Rocket.Chat prior to 8.5.0 Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, Rocket.Chat's CAS login handler forwards the client-supplied options.cas.credentialToken value straight into a MongoDB findOne({_id: ...}) query without any runtime type check. TypeScript's string parameter annotation is erased at runtime, so an unauthenticated attacker can substitute a MongoDB query operator ({"$gt": ""}, {"$ne": null}, etc.) for what the server expects to be an opaque ticket string. The injected operator matches the first unexpired document in the credential_tokens collection, bypassing the CAS ticket check entirely. When any legitimate CAS or SAML SSO login is in flight, the attacker's next DDP login call matches the same credential-token row via the NoSQL operator and is issued a full Meteor auth token (userId + token) bound to the victim. The token is immediately usable against the complete REST and DDP surface as that user. If the victim is an administrator, this escalates to full instance compromise via Apps-Engine app install. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.	Rocket Chat
CVE-2026-45687	Jun 24, 2026	Rocket.Chat 8.x MongoDB Write Bypass in sendFileMessage DDP (v8.5.0+) Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, Rocket.Chat's sendFileMessage DDP method passes the entire attacker-supplied file object into Uploads.updateFileComplete, which merges it directly into a MongoDB $set update via Object.assign. There is no allow-list of writable fields. An attacker can therefore rewrite any column on their own upload record, notably store and the store-specific path fields. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.	Rocket Chat