Rocket.Chat CVE-2026-55759

Exploitation requires that the target Rocket.Chat server has the 'Sign in with Apple' authentication method enabled, and that the attacker possesses a valid, Apple-signed identity token (JWT) for the victim user. The description names the concrete sources: server logs containing the token, an intercepted sign-in flow, or another application that shares the same Apple developer team (whose tokens carry a signature Rocket.Chat will accept). Limiting factors: deployments without Apple Sign-In configured are not exploitable; the attacker cannot forge a token (the signature is verified) and must capture a genuine one, which is why CVSS rates AC:H. Offsetting that limit, the token never expires for replay purposes once captured, so there is no time-window constraint and no additional Rocket.Chat authentication or user interaction is required to replay it.

The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, base 7.4) is internally consistent with the description: exploitation is network-reachable and unauthenticated to Rocket.Chat itself (PR:N), but rated high complexity (AC:H) because the attacker must first obtain a valid Apple identity token for the target - from server logs, an intercepted sign-in flow, or a co-located app sharing the same Apple developer team. That precondition is the dominant risk limiter: this is not a spray-and-pray remote exploit but a targeted account-takeover requiring access to a victim's token. There is no EPSS score, no KEV listing, and no POC in the provided data, so all real-world-exploitation signals are absent or unknown - consistent with a targeted rather than mass-exploitable issue. Once a token is obtained, however, the absence of any expiry on the replay window materially raises severity, since a single leaked token grants persistent impersonation. Net: a genuine high-severity authentication flaw, but realistic priority hinges on whether Apple tokens are exposed (e.g., logged) in a given deployment.

An attacker obtains a target user's Apple identity token - for example by reading it from exposed Rocket.Chat or reverse-proxy logs, intercepting it during a sign-in flow, or extracting it from a separate app that shares the victim organization's Apple developer team. They then submit that Apple-signed JWT to the vulnerable Rocket.Chat Apple Sign-In endpoint, which accepts it because only the signature and a non-empty iss are checked, and are authenticated as the victim. No POC was identified in the provided data, and the high attack complexity reflects the need to first acquire a valid token.