CVE-2026-55954: Missing ID token claim validation in ueberauth_apple allows account takeover
Authentication Bypass by Spoofing vulnerability in ueberauth ueberauth_apple allows account takeover via unvalidated ID token claims.
The Ueberauth.Strategy.Apple.Token.payload/2 function verifies the JWT signature of the callback id_token against Apple's JWKS but does not validate any registered claims. The iss, aud, exp, and iat claims are read from the token and passed on to Ueberauth.Strategy.Apple.handle_callback!/1, which derives the logged-in user's uid and email directly from the unvalidated sub claim.
An attacker who obtains any Apple-signed ID token bearing the victim's sub (via a captured expired token, or via an ID token issued to a sibling client in the same Apple developer team) can replay it against the vulnerable callback and be authenticated as the victim. The absent exp check makes stolen tokens usable indefinitely, and the absent aud check enables cross-application account takeover across clients that share an Apple developer team.
This issue affects ueberauth_apple: from 0.1.0 before 0.6.2.
Security readout for executives and security teams
Plain-English summary
Applications using vulnerable ueberauth_apple for Sign in with Apple may let an attacker log in as another user if they possess a qualifying Apple-signed ID token. The library verified the token signature but failed to check key claims that prove the token is current and intended for that application.
Executive priority
Treat as urgent for any customer-facing Apple login flow. The impact is account takeover, the CVSS score is 9.1, and the fix is identified. Prioritize inventory and upgrade over broad compensating controls.
Technical view
Ueberauth.Strategy.Apple.Token.payload/2 validates the JWT signature against Apple JWKS but does not validate iss, aud, exp, or iat. handle_callback!/1 then derives uid and email from the unvalidated sub claim. Sources state ueberauth_apple versions from 0.1.0 before 0.6.2 are affected.
Likely exposure
Exposure is limited to Elixir/Phoenix applications that use ueberauth_apple versions before 0.6.2 for Apple authentication, especially where Apple developer team clients are shared across applications.
Exploitation context
No active exploitation is cited, and KEV is false. The source bundle describes replay risk using a captured expired Apple ID token or a token issued to a sibling client in the same Apple developer team.
Researcher notes
Focus validation on claim enforcement, not signature verification alone. The key exposure is acceptance of Apple-signed tokens without iss, aud, exp, or iat checks, allowing stale-token replay and cross-client acceptance as described by the advisory.
Mitigation direction
Upgrade ueberauth_apple to version 0.6.2 or later.
Review the GitHub advisory and patch notes before deployment.
Invalidate sensitive sessions after upgrading, based on business risk.
Audit Apple authentication logs for unusual cross-client or stale-token sign-ins.
Check vendor guidance if upgrade constraints exist.
Validation and detection
Check dependency manifests and lockfiles for ueberauth_apple versions below 0.6.2.
Confirm Apple login callbacks reject expired tokens.
Confirm callbacks reject tokens with the wrong audience.
Review code paths deriving user identity from Apple ID token claims.
Verify production deployments run the fixed dependency version.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-290: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
5Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-290 · source CWE mapping
Authentication Bypass by Spoofing
Authentication Bypass by Spoofing represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.