Authlib EUVD-2026-108519

Exploitation requires ALL of the following: (1) the relying party uses OIDC implicit or hybrid flow, OR calls OpenIDMixin.parse_id_token() directly on externally supplied ID tokens - plain authorization code flow is NOT affected because the token is fetched over TLS after a state lookup; (2) the attacker possesses a captured, validly signed ID token belonging to the victim that passes signature, iss, and aud validation; and critically (3) that captured token must itself carry the nonce_supported claim as a JSON boolean false - the attacker cannot add or alter this claim without invalidating the signature, so the issuing authorization server must emit it (the Apple-style provider case per issue #259). A string value "false" does NOT trigger the bypass. Affects both sync and async integrations (Flask, Django, Starlette) on authlib <= 1.8.0. The strong limiting factor is condition (3): only tokens originally issued with nonce_supported:false are exploitable, which is why complexity is high. No RP-side authentication or special configuration is required of the attacker. No integrator-side mitigation exists; upgrading to 1.9.0 is the only fix.

Signals are moderate and partially conflicting. The NVD CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N = 4.2) and the GHSA advisory vector agree on exploitability metrics but diverge sharply on impact: GHSA rates C:H/I:H (6.8, account takeover at the relying party) while NVD rates C:L/I:L (4.2) - this impact disagreement should be resolved toward GHSA's view, since a successful replay authenticates the attacker as the victim and grants full access to the victim's RP account. No EPSS score and no CISA KEV entry are present in the input, so there is no evidence of active or widespread exploitation; the vuln.today Decision label is 'this_month', not act_now or emergency, consistent with a fix-in-normal-cycle priority. A detailed proof-of-concept (full poc.py with reproduced three-case output) is published in the GHSA advisory. The AC:H rating is well-founded: exploitation requires a validly signed victim token that already carries the nonce_supported JSON boolean false claim (the attacker cannot inject it without breaking the signature), and the RP must use implicit/hybrid flow or call parse_id_token() directly. These stacked preconditions make this a real but targeted authentication-bypass risk rather than a mass-exploitable critical issue - a genuine priority for affected OIDC relying parties, but not an emergency.

An attacker obtains a victim's validly signed OIDC ID token that carries nonce_supported:false (captured from browser history, a Referer header, proxy/server logs, or a shared device, where the issuing authorization server emits that claim). The attacker replays the token into their own session at a relying party that uses implicit/hybrid flow or that passes externally supplied tokens to parse_id_token(); nonce-to-session binding is skipped and the RP establishes an authenticated session as the victim. A working proof-of-concept demonstrating acceptance of a mismatched-nonce token is published in the GHSA advisory.