pow-auth Assent CVE-2026-117656

The target application must use Assent's Sign in with Apple strategy (Assent.Strategy.Apple) at a version from 0.1.25 up to but not including 0.3.2, AND must rely on the returned Apple sub or email for account lookup, linking, verification, or access control - that reliance is what turns the override into impersonation. No special server configuration is needed; the flaw is in the strategy's default callback handling (fetch_user/2 merges the client-controlled user parameter over the verified ID token claims). Limiting factors: the attacker must still complete a genuine Sign in with Apple login with their own Apple ID to reach the callback, and applications that do not key identity off the Apple-provided sub/email are not meaningfully affected. The documented workaround is to delete the user parameter (Map.delete("user")) before calling the strategy; version 0.3.2 ignores the parameter by default.

This is a genuine high-priority issue, not a high-CVSS-but-low-real-risk case. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N, score 9.3) is internally consistent with the mechanism described: a network-reachable, low-complexity authentication-bypass where the attacker needs no pre-existing privileges on the target and no victim interaction, yielding high confidentiality and integrity impact through account impersonation (availability is correctly N). The vuln.today decision label is act_now and a vendor patch is available, reinforcing urgency. Key caveats: this is NOT listed in CISA KEV and no EPSS score was provided, so there is no evidence of active exploitation or a modeled exploitation probability - the urgency rests on the act_now decision label, the trivial and well-documented attack technique, and the severity of the impact rather than on confirmed in-the-wild use. The input references include the fixing commits and a GHSA advisory but do NOT state that working public exploit code exists, so exploitation capability should be treated as easily reproducible from the public advisory rather than as a confirmed packaged exploit. One nuance limiting blast radius: impact is conditional on how the consuming application uses the returned identity - only apps that look up, link, or authorize accounts by the Apple sub or email are actually exploitable.

An attacker completes a legitimate Sign in with Apple flow using their own Apple ID, then intercepts and edits the browser-submitted user form parameter on the authorization callback to the target application, setting sub and email to those of a victim. Because Assent merges this unverified parameter over the verified ID token claims, the application receives the victim's identity and logs the attacker in as, or links their session to, the victim's account. No special configuration is required and no public working exploit is identified, but the technique is fully described in the vendor advisory.