CVE-2026-55954: Ueberauth Apple Auth Bypass Vulnerability

CVE-2026-55954 Overview

CVE-2026-55954 is an Authentication Bypass by Spoofing vulnerability [CWE-290] in the ueberauth_apple Elixir library, which provides Sign in with Apple support for the Ueberauth authentication framework. 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 the registered claims. Attackers who obtain any Apple-signed ID token bearing a victim's sub claim can replay it against a vulnerable callback and authenticate as that victim. The flaw affects ueberauth_apple versions 0.1.0 through 0.6.1, and is fixed in 0.6.2.

Critical Impact
An attacker with any Apple-signed ID token referencing a victim's sub claim can take over the victim's account across all applications sharing an Apple developer team.

Affected Products

ueberauth_apple versions 0.1.0 through 0.6.1
Elixir and Phoenix applications using Ueberauth.Strategy.Apple for Sign in with Apple
Deployments sharing an Apple developer team with other client applications

Discovery Timeline

2026-07-14 - CVE-2026-55954 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-55954

Vulnerability Analysis

The vulnerability resides in how ueberauth_apple processes the id_token returned during the Sign in with Apple OAuth callback. The Ueberauth.Strategy.Apple.Token.payload/2 function correctly verifies the token's cryptographic signature against Apple's JSON Web Key Set (JWKS), confirming the token was issued by Apple. However, the strategy does not validate any of the registered JWT claims after signature verification.

The iss (issuer), aud (audience), exp (expiration), and iat (issued-at) claims are read from the token and forwarded to Ueberauth.Strategy.Apple.handle_callback!/1. That function derives the authenticated user's uid and email directly from the unvalidated sub claim. Any Apple-issued token containing the victim's sub therefore results in successful authentication as the victim.

Root Cause

The root cause is the absence of registered-claim validation on a cryptographically verified JWT. Signature verification alone confirms provenance, not intended recipient, validity window, or scope. Without checking aud, the library accepts tokens issued for any sibling client that shares the same Apple developer team, enabling cross-application account takeover. Without checking exp, previously captured tokens remain replayable indefinitely.

Attack Vector

An attacker acquires an Apple-signed ID token that contains the victim's sub claim. Sources include expired tokens captured from logs, proxies, or client storage, and tokens legitimately issued to a different application belonging to the same Apple developer team. The attacker submits this token to the vulnerable ueberauth_apple callback endpoint. Because no aud or exp validation occurs, the token is accepted and the attacker is logged in as the victim.

text

# Patched version bump in mix.exs
 defmodule UeberauthApple.Mixfile do
   use Mix.Project

-  @version "0.6.1"
+  @version "0.6.2"
   @url "https://github.com/ueberauth/ueberauth_apple"

Source: GitHub Commit 01e2d9c

Detection Methods for CVE-2026-55954

Indicators of Compromise

Successful authentication events on Apple OAuth callbacks using id_token values with exp claims in the past.
Callback requests carrying id_token values whose aud claim does not match the local application's Apple client identifier.
Repeated logins for the same account originating from unusual IP addresses or user agents in short succession.
Duplicate use of the same id_tokenjti or identical raw token across separate sessions.

Detection Strategies

Parse id_token values received at the /auth/apple/callback route and log iss, aud, exp, and iat for offline verification.
Alert when an accepted token has aud values belonging to sibling applications rather than the current client.
Correlate Apple sign-in events with prior sign-in history for the same sub to detect device or geolocation anomalies.

Monitoring Recommendations

Ingest Phoenix and Ueberauth authentication logs into a centralized SIEM or data lake for retention and analysis.
Track the deployed version of ueberauth_apple across all services and flag any instance below 0.6.2.
Monitor for spikes in Sign in with Apple callback traffic that could indicate token replay probing.

How to Mitigate CVE-2026-55954

Immediate Actions Required

Upgrade ueberauth_apple to version 0.6.2 or later in every affected Elixir application.
Audit recent Sign in with Apple authentication events for tokens with expired exp values or mismatched aud claims.
Invalidate active sessions established through the vulnerable callback and require re-authentication.
Rotate any Apple Sign in with Apple client secrets used by the affected applications.

Patch Information

The fix is included in ueberauth_apple0.6.2, released in commit 01e2d9c. Full technical details are available in the GitHub Security Advisory GHSA-pxx8-68pc-p9mr and the CNA CVE-2026-55954 Advisory. Additional metadata is published at OSV EEF-CVE-2026-55954.

Workarounds

If patching cannot be performed immediately, wrap the callback handler to independently validate the id_token claims (iss equals https://appleid.apple.com, aud equals the configured client ID, and exp is in the future).
Restrict the Apple developer team membership to the minimum set of applications to reduce cross-client token replay exposure.
Temporarily disable the Sign in with Apple strategy on internet-facing services until the upgrade is deployed.

bash

# Update the dependency in mix.exs, then fetch and compile
# {:ueberauth_apple, "~> 0.6.2"}
mix deps.update ueberauth_apple
mix deps.get
mix compile