Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Network-reachable and unauthenticated to Rocket.Chat (PR:N), but AC:H because the attacker must first obtain a valid Apple token; full account takeover gives C:H/I:H, no availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Authentication bypass in Rocket.Chat's Apple Sign-In handler allows attackers to impersonate any user by replaying a captured Apple identity token. The handler verifies the JWT signature but skips validation of the aud, exp, nbf, and nonce claims, so any Apple-signed token with a non-empty iss is accepted indefinitely with no replay-window expiry. Affected versions are those prior to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, and 7.10.13; no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Technical ContextAI
The root cause is CWE-287 (Improper Authentication) in Rocket.Chat's 'Sign in with Apple' OAuth/OIDC integration. Sign in with Apple issues a signed JWT (identity token) where security depends on validating both the signature AND the registered claims: aud (audience, must equal the relying party's client/team ID), exp/nbf (token lifetime window), and nonce (binds the token to a specific authentication request to prevent replay). Rocket.Chat's handler validated only the cryptographic signature against Apple's public keys and confirmed iss was non-empty, but never checked aud, exp, nbf, or nonce. Because Apple signs all tokens for a given developer team with the same keys, any token legitimately minted for one application (or a sibling app on the same Apple developer team) carries a valid signature and is therefore accepted by Rocket.Chat as proof of identity. The affected product per CPE is cpe:2.3:a:rocketchat:rocket.chat across all versions prior to the fixed releases.
RemediationAI
Vendor-released patch: upgrade to 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, or 7.10.13 - choose the patched release matching your current minor branch, per the advisory at https://github.com/RocketChat/Rocket.Chat/security/advisories/GHSA-c75c-5hc7-j4vp. If immediate upgrade is not possible, the most effective compensating control is to disable the Apple Sign-In authentication method in Rocket.Chat administration, which fully removes the vulnerable code path at the cost of blocking legitimate Apple-based logins. Additionally, audit and scrub server and proxy logs that may have captured Apple identity tokens and tighten log access, since leaked tokens are the primary attack input; if Apple login must remain enabled, also rotate the Apple Sign-In service/client configuration so previously issued tokens for unrelated apps cannot be reused. Note these are stopgaps - only the patched versions actually enforce aud/exp/nbf/nonce validation.
More in Rocket Chat
View allA sanitization vulnerability exists in Rocket.Chat server versions <3.13.2, <3.12.4, <3.11.4 that allowed queries to an
A improper input sanitization vulnerability exists in Rocket.Chat server 3.11, 3.12 & 3.13 that could lead to unauthenti
A improper authentication vulnerability exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 that allowed two factor authentic
A SQL injection vulnerability exists in Rocket.Chat <v3.18.6, <v4.4.4 and <v4.7.3 which can allow an attacker to retriev
A Server-Side Request Forgery (SSRF) affects Rocket.Chat's Twilio webhook endpoint before version 6.10.1. Rated high sev
An information disclosure vulnerability exists in the Rocket.Chat server fixed v3.13, v3.12.2 & v3.11.3 that allowed ema
An improper authentication vulnerability exists in Rocket.Chat Mobile App <4.14.1.22788 that allowed an attacker with ph
A cleartext transmission of sensitive information exists in Rocket.Chat <v5, <v4.8.2 and <v4.7.5 relating to Oauth token
An information disclosure vulnerability exists in Rocket.Chat <v5 due to the getUserMentionsByChannel meteor server meth
Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript. Rated medium severity
Rocket.Chat through 3.4.2 allows XSS where an attacker can send a specially crafted message to a channel or in a direct
Rocket.Chat before 2.1.0 allows XSS via a URL on a ![title] line. Rated medium severity (CVSS 6.1), this vulnerability i
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39120