CVE-2026-116672: 
Python vulnerability analysis and mitigation

CVE-2026-116672 is an authorization bypass vulnerability in Authlib, a Python library for building OAuth and OpenID Connect servers. The flaw exists in the documented reference implementations of ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission for RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol), which fail to verify that a presented registration access token belongs to the target client. All versions from 0.15 through 1.9.0 are affected; the issue is fixed in version 1.9.1. It carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-1188 (Insecure Default Initialization of Resource). The authenticate_client example in authlib/oauth2/rfc7592/endpoint.py looks up the target client solely from the attacker-controlled client_id in the request payload, while check_permission only verifies whether the target client is generally "editable" — neither method checks that request.credential (the authenticated token) actually belongs to the target client. An attacker with any valid registration_access_token for any client can supply an arbitrary client_id in the request to read, modify, or delete a completely different client's registration. The fix (commit 1bd2a31) adds an explicit token.check_client(client) call in create_configuration_response and updates the documented examples to extract client_id from the URL path rather than the request body (GitHub Advisory, Fix Commit).

Any authenticated client holding a valid registration access token can read, modify, or delete any other client's registration record over the network. Modifying redirect_uris to an attacker-controlled endpoint enables interception of authorization codes or OAuth tokens for victim clients' users, constituting a high confidentiality and integrity impact. Deleting client registrations causes denial of service for affected clients. In open dynamic registration deployments — where self-registration requires no initial access token — this effectively reduces to an unauthenticated attack, since an attacker can freely self-register to obtain a qualifying token (GitHub Advisory).

No public proof-of-concept exploit or evidence of in-the-wild exploitation has been observed as of the disclosure date (Feedly). The EPSS score is 0.0, indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. However, exploitability is practically low-barrier in open dynamic registration deployments, as an attacker only needs to self-register a throwaway client to obtain a valid token, then target any other client by guessing or enumerating its client_id (GitHub Advisory).

1. Reconnaissance: Identify a target authorization server built with Authlib's ClientConfigurationEndpoint using versions 0.15–1.9.0, and locate the RFC 7591 dynamic client registration endpoint (commonly /oauth/register or similar).
2. Self-register a throwaway client: Send an unauthenticated (or minimally authenticated) POST request to the registration endpoint to register a new client, receiving client_id_A and registration_access_token_A.
3. Identify target client: Enumerate or guess client_id_B belonging to a different, legitimate client on the same server (client IDs may be predictable or discoverable via error messages).
4. Send cross-client request: Issue a GET, PUT, or DELETE request to the client configuration endpoint for the target (e.g., GET /oauth/register/client_id_B) with the header Authorization: Bearer registration_access_token_A.
5. Bypass authorization: Because authenticate_client looks up client_id_B from the request without checking token binding, and check_permission only verifies client_B.editable, the server processes the request as if authorized.
6. Achieve objective: Read victim client metadata (including secrets), modify redirect_uris to an attacker-controlled URL to intercept future authorization codes/tokens, or delete the client registration to deny service (GitHub Advisory).

• Network: Unexpected GET, PUT, or DELETE requests to the client configuration endpoint (e.g., /oauth/register/<client_id>) where the client_id in the URL does not match the client associated with the Authorization: Bearer token in server logs.
• Logs: OAuth server access logs showing a single registration_access_token used to access multiple distinct client_id paths; HTTP 200 responses to configuration endpoint requests from clients that do not own the targeted registration.
• Application State: Unexpected changes to redirect_uris for registered clients, particularly to external or unknown domains; sudden deletion of client registrations with no corresponding administrative action recorded.
• Process/Behavior: Spike in dynamic client registrations (RFC 7591) followed immediately by configuration endpoint (RFC 7592) requests from the newly registered clients targeting other client IDs (GitHub Advisory).

Upgrade Authlib to version 1.9.1, which adds an explicit token.check_client(client) binding check in create_configuration_response and corrects the documented examples (Release v1.9.1, Fix Commit). If immediate upgrading is not possible, review custom implementations of authenticate_client and check_permission and add an explicit check such as request.credential.client_id == client.get_client_id() in check_permission. Additionally, ensure authenticate_client reads client_id from the URL path rather than the request body, as GET and DELETE requests have no body (GitHub Advisory).

The vulnerability was reported by researcher alham-rizvi and the advisory was published by Authlib maintainer azmeuk (Éloi Rivard) on October 14, 2026. The advisory notes that this is a documentation and reference-implementation issue rather than a flaw enforced unconditionally by the library, since the affected methods are abstract and must be implemented by developers — making it particularly insidious for those who followed the official documentation exactly as written (GitHub Advisory).