Unverified Sign in with Apple callback parameter can override verified ID token claims
Only affects Assent 0.1.25 before 0.3.2 in apps that use the Sign in with Apple strategy and receive the callback's user parameter. Fixed in 0.3.2.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Fix
- Fixed in 0.3.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The affected software is the Sign in with Apple strategy in the pow-auth Assent library, an Elixir authentication library used by applications that support Apple login. The flaw lets an attacker who signs in with their own Apple ID alter the user data returned after login, such as the subject identifier and email address, so the application may treat the attacker as a different, existing user.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability in the Sign in with Apple strategy in pow-auth Assent allows an unauthenticated remote attacker to impersonate another user via the user parameter of the authorization callback. Apple posts the user's name to the callback endpoint in a user form parameter that the browser submits and the client controls. Assent.Strategy.Apple.callback/2 in lib/assent/strategies/apple.ex decodes that parameter, and fetch_user/2 merges it over the claims of the verified ID token, so the unverified map wins. An attacker who completes a Sign in with Apple login with their own Apple ID and edits the user parameter can replace sub, email, and any other claim. Applications that look up, link, or authorize accounts by the returned subject or email then act on the attacker's values. This issue affects assent: from 0.1.25 before 0.3.2.
Timeline
- CVE published1 day
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- assent
From 0.1.25 · fixed in 0.3.2
- pow-auth/assent
Version range not reported
References 5
GitHub · pow-auth/assent
cna.erlef.org
Questions about CVE-2026-117656
What does this mean?
Apple posts the user's name to the callback in a user form parameter that the browser submits and the client controls. In affected versions, that parameter can override verified ID token claims such as sub and email, so the application receives attacker-chosen identity fields marked as verified and can be led to impersonate another user.Source: cna.erlef.org, github.com
Am I affected, and how do I check?
The issue affects the assent Hex package from 0.1.25 before 0.3.2, or the git range a2d331e to 18898bd. It matters only where the application uses Assent.Strategy.Apple and the callback receives the user parameter. Check the assent version in your mix.lock or dependency list, and check whether Assent.Strategy.Apple is used in the callback flow.Source: cna.erlef.org, github.com
What should I do about it?
Upgrade assent to 0.3.2 or later, which ignores the callback's user parameter by default. If an upgrade is not possible, remove the user parameter from the callback params before calling the strategy, for example with Map.delete(params, "user").Source: cna.erlef.org, github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data