ueberauth_apple CVE-2026-55954

Exploitation requires the attacker to first possess a genuine Apple-signed id_token containing the victim's sub claim - obtained either as a captured/expired token for the victim or as a token Apple issued to a different (sibling) client within the same Apple developer team as the target. Given such a token, it can be replayed against the vulnerable /auth callback with no authentication, no user interaction, and against default configurations of any app running ueberauth_apple 0.1.0-0.6.1 (the missing exp check makes stolen tokens valid indefinitely, and the missing aud check enables cross-client reuse). The limiting factor, reflected as AT:P in the CVSS 4.0 vector, is precisely this token-acquisition prerequisite: without access to a victim-scoped Apple-signed token the attack cannot proceed, which favors insiders/siblings in a shared developer team or attackers who have intercepted a prior token over anonymous internet-wide attackers.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N, base 9.1) captures the profile well: network-reachable, low complexity, no privileges or user interaction, high confidentiality and integrity impact from account takeover, no availability impact. The AT:P (Attack Requirement: Present) is the crucial nuance and matches the description - the attacker must first obtain an Apple-signed token bearing the victim's sub (a captured expired token or one issued to a sibling client in the same developer team), which is a real but non-trivial precondition that separates this from a wholly opportunistic bug. No EPSS score and no KEV status were supplied, so real-world exploitation frequency cannot be quantified; no public exploit was identified either. Net assessment: a genuine high-priority vulnerability for any Elixir app using this library, but exploitation is gated on token acquisition rather than being spray-and-pray, so treat it as targeted account-takeover risk rather than mass exploitation.

An attacker in the same Apple developer team obtains an id_token that Apple issued to a sibling Services ID for a victim who signed into that other app. Because the vulnerable callback ignores the aud and exp claims, the attacker POSTs this legitimately-signed token to the target application's Apple callback endpoint and is authenticated as the victim (matching sub), completing a cross-application account takeover. No public exploit code was identified, but the replay is straightforward given a valid signed token and network access to the callback.