Which versions of ueberauth_apple are affected by CVE-2026-55954?

The Elixir ueberauth_apple library used for Apple-based authentication contains a critical flaw allowing attackers to hijack user accounts without detection.. A patch is available.

How to fix or mitigate CVE-2026-55954?

Within 24 hours, identify and inventory all applications using ueberauth_apple versions 0.1.0 through 0.6.1, and flag these systems for emergency patching with security and engineering teams. Within 7 days, deploy version 0.6.2 or later across all affected environments, beginning with production systems serving customer-facing applications. Within 30 days, complete a review of authentication logs spanning the prior 90 days to detect any anomalous login patterns or unauthorized account access that may indicate exploitation.

ueberauth_apple CVE-2026-55954

Q: What is the CVSS score of CVE-2026-55954?

CVE-2026-55954 has a CVSS 4.0 base score of 9.1 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-43706 CRITICAL

Authentication Bypass by Spoofing (CWE-290)

2026-07-14 EEF

Authentication Bypass Apple Ueberauth Apple Ueberauth

9.1

CVSS 4.0 · Vendor: EEF

Severity by source

Vendor (EEF) PRIMARY

9.1 CRITICAL

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.7 HIGH

Network-reachable unauthenticated replay, but AC:H because the attacker must first obtain a victim-scoped Apple-signed token; S:C as auth is broken across a sibling client, high C/I from account takeover, no availability impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 14, 2026 - 16:02 vuln.today

Analysis Generated

Jul 14, 2026 - 16:02 vuln.today

CVE Published

Jul 14, 2026 - 15:08 cve.org

CRITICAL 9.1

DescriptionCVE.org

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.

AnalysisAI

Authentication bypass by spoofing in the Elixir ueberauth_apple strategy (0.1.0 through 0.6.1) allows full account takeover because the callback id_token's signature is checked against Apple's JWKS but its registered claims are never validated. Remote unauthenticated attackers who obtain any Apple-signed token carrying the victim's sub - an expired token or one issued to a sibling client in the same Apple developer team - can replay it to log in as the victim. No public exploit identified at time of analysis, but the vendor-confirmed fix (0.6.2) and a clear replay path make this a high-priority auth flaw; EPSS and KEV data were not provided.

Technical ContextAI

ueberauth_apple is an Elixir/Phoenix OAuth strategy plugging 'Sign in with Apple' into the Ueberauth authentication framework (CPE cpe:2.3:a:ueberauth:ueberauth_apple). The flaw is a classic CWE-290 (Authentication Bypass by Spoofing) rooted in incomplete JWT validation: Ueberauth.Strategy.Apple.Token.payload/2 correctly verifies the id_token's RS256 signature against Apple's published JWKS, proving Apple signed the token, but then reads the iss, aud, exp, and iat claims without enforcing them. Because handle_callback!/1 derives the user's uid and email straight from the unvalidated sub claim, any token Apple ever signed for that subject is accepted regardless of intended audience or expiry. Signature validity alone is insufficient for OIDC/JWT security - the aud claim binds a token to a specific client and exp bounds its lifetime, so omitting these checks turns a valid-but-foreign token into a universal credential.

RemediationAI

Vendor-released patch: upgrade ueberauth_apple to 0.6.2 or later (update the dep to {:ueberauth_apple, "~> 0.6.2"} and run mix deps.update ueberauth_apple), which validates the iss, aud, exp, and iat claims after signature verification and fails closed when the expected client_id audience cannot be determined; the maintainers note client_id was already required so the fix should not break existing configurations. The corrective commit is https://github.com/ueberauth/ueberauth_apple/commit/01e2d9c9b3134e1b78633ad82d136d5ff4a61f28 and details are in advisory GHSA-pxx8-68pc-p9mr. If you cannot upgrade immediately, compensating controls include enforcing claim validation upstream (e.g. reject callbacks whose id_token aud does not equal your configured Services ID / client_id and whose exp is in the past) at a reverse proxy or in a custom wrapper before handle_callback!/1, and ensuring your Apple client is not grouped in a developer team with untrusted sibling clients - the trade-off is added integration complexity and that proxy-level JWT inspection duplicates logic the 0.6.2 fix already provides, so patching remains strongly preferred.