Authlib EUVD-2026-108521

Exploitation requires all of the following, drawn directly from the advisory's preconditions: the authorization server must register OpenIDImplicitGrant (or a subclass); the attacker must control a registered OAuth client whose metadata permits an OIDC implicit response type (id_token or id_token token); that client's allowed scopes must exclude openid but include a claim-bearing scope such as profile; the client sends an authorization request adding openid (e.g. scope=openid profile) with a nonce; and a user must log in and approve the request. The limiting factors are significant: attacker must already be a registered/permitted client (PR:L), the flaw is gated by user login and active consent (UI:R), the issued ID token's audience is the attacking client, and deployments are NOT affected if they use only the OIDC authorization-code flow or if every client permitted an id_token response type is also allowed the openid scope.

This is a genuine but constrained authorization flaw, best treated as a measured-priority fix rather than an emergency, consistent with the input's 'this_month' decision label. The supplied CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N, base 4.6, Medium) aligns well with the mechanism: network-reachable, low attack complexity, but requiring an already-registered OAuth client (PR:L) and active user login plus consent (UI:R). No EPSS score was provided and the CVE is not in CISA KEV, so there is no signal of widespread or automated exploitation. The GitHub advisory describes a reporter-verified reproduction (a pytest PoC and a standalone Flask provider driven by curl), so a public PoC reference exists; it is not verified as published, distributable working exploit code. The reporter and CWE-863 (Incorrect Authorization) both frame this as an authorization/scope-restriction bypass, not an authentication bypass as the input Tags suggest. The practical ceiling on risk is real: the attacker must operate a registered client that the operator deliberately permitted an id_token response type while withholding the openid scope, the victim user must log in and approve, and the resulting ID token's audience is the attacking client itself. Deployments using only the OIDC authorization-code flow, or that grant openid to every client allowed an id_token response, are explicitly not affected. Net: a legitimate confidentiality/authorization concern for OIDC implicit-grant deployments, worth patching on a normal maintenance cadence, but not a high-urgency internet-wide threat.

An operator registers an OAuth client with Authlib's OpenIDImplicitGrant, permitting it an id_token (or id_token token) response type and the profile scope but deliberately not the openid scope. The malicious client sends an authorization request adding openid to its scopes with a nonce; a legitimate user logs in and approves what the consent page shows only as 'profile', and the server returns a signed ID token carrying the user's sub and profile claims. A reporter-verified PoC (pytest and a curl-driven Flask provider) exists in the GitHub advisory, but exploitation still requires attacker control of a registered client plus victim login and consent.