Authlib CVE-2026-116672

Exploitation requires a deployment that (1) exposes Authlib's RFC 7592 ClientConfigurationEndpoint and (2) implemented authenticate_client and check_permission by following the vulnerable docstring examples - i.e. resolving the target client purely from the request-supplied client_id and checking only client.editable, never comparing request.credential to the target client. The attacker must present any valid registration_access_token (for any client) and know or guess the target client_id. The key limiting factor is correct implementation: servers that already bind the token to the target client are unaffected, so this does not hit every Authlib user. The major amplifying factor is the common open/anonymous RFC 7591 registration model, where an attacker can self-issue a qualifying token for free, reducing the practical barrier to near zero. Authentication is formally required (CVSS PR:L: a valid registration access token), but that token need not relate to the victim client. Fixed in 1.9.1.

Signals point to a genuine but conditional priority rather than a mass-exploitation emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N, C:H/I:H/A:H, base 8.8 High) describes network-reachable, low-complexity abuse requiring only low privilege and no user interaction, with full confidentiality, integrity and availability impact on the targeted client registration - consistent with the CWE-639 authorization-bypass mechanism. The vuln.today decision label is 'this_week', which matches a serious-but-not-emergency posture. Tempering that: there is no CISA KEV listing and no EPSS score in the input, so there is no evidence of active or widespread exploitation - treat exploitation likelihood as unquantified rather than low. The crucial caveat is that this is effectively a documentation-induced flaw: only deployments whose developers implemented authenticate_client and check_permission by copying the vulnerable docstring examples (lookup by request client_id plus a bare client.editable check, never binding request.credential to the target) are affected, so PR:L understates the gating condition. Conversely, PR:L arguably overstates the barrier in the common open RFC 7591 registration model, where any attacker can self-issue a qualifying token for free - in that configuration the effective privilege requirement collapses. No full SSVC decision (automatable / technical-impact) is supplied in the input, so those cells cannot be cross-referenced.

In an authorization server using Authlib's RFC 7592 ClientConfigurationEndpoint implemented per the vulnerable docstring examples, and running the common open RFC 7591 dynamic-registration model, an attacker self-registers a throwaway client to obtain a valid registration_access_token, then sends PUT /register/{victim_client_id} with that token, rewriting the victim's redirect_uris to an attacker-controlled endpoint to intercept authorization codes or tokens (or DELETE to deny service). The GHSA-c73q-w75p-j82v advisory publishes full step-by-step reproduction, but the input confirms no packaged/weaponized exploit tool.