---
title: Authlib CVE-2026-116672: OAuth servers built from the RFC 7592 docstring examples let any client's registration token read, rewrite or delete other clients | ctxsec
url: https://ctxsec.com/items/authlib-1-9-1-cve-2026-116672-rfc7592-client-config-token-binding
description: "Authlib's dynamic client registration management endpoint left the token-to-client binding check to developers, and the documented examples never performed it. Servers built from those examples accept any valid registration_access_token for any client_id, so an attacker who self-registers a throwaway client can read another client's registration, change its redirect_uris to steal authorization codes, or delete it. Authlib 1.9.1 enforces the binding (CVSS 8.8)."
status: "official (Authlib GitHub advisory GHSA-c73q-w75p-j82v; fix in 1.9.1)"
published: 2026-11-01
---

> Authlib's dynamic client registration management endpoint left the token-to-client binding check to developers, and the documented examples never performed it. Servers built from those examples accept any valid registration_access_token for any client_id, so an attacker who self-registers a throwaway client can read another client's registration, change its redirect_uris to steal authorization codes, or delete it. Authlib 1.9.1 enforces the binding (CVSS 8.8).

[← Cybersecurity News](/news) · [markdown](/items/authlib-1-9-1-cve-2026-116672-rfc7592-client-config-token-binding.md)

official (Authlib GitHub advisory GHSA-c73q-w75p-j82v; fix in 1.9.1)

2026-11-01

### Authlib CVE-2026-116672: OAuth servers built from the RFC 7592 docstring examples let any client's registration token read, rewrite or delete other clients

An advisory from the **Authlib** project (**GHSA-c73q-w75p-j82v**, **CVE-2026-116672**, CVSS 3.1 **8.8**, Authlib **0.15 to 1.9.0**) covers its RFC 7592 `ClientConfigurationEndpoint`.

- **Bug:** the endpoint calls `authenticate_token`, `authenticate_client` and `check_permission`, which developers must implement. The shipped docstring examples look the target client up from the request's `client_id` and check only `client.editable`, so nothing verifies that the presented `registration_access_token` was issued to _that_ client.
- **Exploit path:** where RFC 7591 registration is open (common), an attacker registers a throwaway client, takes its token, and sends `GET/PUT/DELETE /register/<victim_client_id>`. A `PUT` can repoint the victim's `redirect_uris` to intercept authorization codes or tokens for that client's users.
- **Fix:** Authlib **1.9.1** (released Oct 14) makes the endpoint reject a registration access token issued to another client, and the docs now read `client_id` from the URL instead of the body.

**What to do:** upgrade to 1.9.1 and review your own `authenticate_client`/`check_permission` implementations: confirm that `request.credential` (the token) maps to the client being accessed. Audit recent client registration updates for changed `redirect_uris`. MCP authorization servers that enable dynamic client registration should treat this as in scope.

Sources: [Authlib advisory GHSA-c73q-w75p-j82v (CVE-2026-116672)](https://github.com/authlib/authlib/security/advisories/GHSA-c73q-w75p-j82v) · [Fix commit 1bd2a31](https://github.com/authlib/authlib/commit/1bd2a313492ce0a4d0571c150730907aa3fc91ff)