- A GitHub advisory says Authlib's documented examples for its RFC 7592 endpoint omit the check that ties a token to one client. Following both examples as written leaves an authorization bypass.
- Where open registration is allowed, the advisory says an attacker can self-issue a token. They can then read, change or delete another client's registration if they know its client_id.
- The advisory lists Authlib 1.9.1 as patched and 1.7.2 as affected. It does not describe the patch, so teams should also check their own copies of the example methods.
Teams copy example code because it saves time and because the library authors wrote it. Here, a GitHub advisory says the copied example is where the flaw lives.
What the advisory says
The GitHub Advisory Database published GHSA-c73q-w75p-j82v on October 30. It covers Authlib, a Python library for building OAuth servers. The advisory lists version 1.7.2 as affected and 1.9.1 as patched. It links to CVE-2026-116672 on the National Vulnerability Database.
The advisory calls this a documentation and reference-code problem. It is not a bug the library forces on every deployment. The library leaves the key checks to developers. The advisory says the only guidance it ships for them is the part that can be exploited.
The advisory is the only source for this story. It is one reporter's assessment, and the story has no vendor statement to set beside it.
How the endpoint is meant to work
RFC 7592 is a standard that lets a registered application read, update or delete its own registration. Each client gets a registration_access_token when it signs up. That token is its proof of identity for later changes.
The advisory says the whole design rests on one comparison. The server must confirm the token belongs to the client named in the request. A token that is valid for some client is not enough.
Authlib's ClientConfigurationEndpoint runs three steps in order: authenticate_token, authenticate_client, then check_permission. The advisory says that order is sound. All three are abstract methods, which means developers must write them in their own subclass.
Where the examples fall short
The advisory focuses on the documented examples for authenticate_client and check_permission. The first example finds the target client using only the client_id in the request. It never looks at the token.
The second example asks only whether the target client is "editable". It also ignores the token.
Authlib saves the authenticated token on request.credential so a later step can compare it with the target. According to the advisory, neither example reads it.
Think of a hotel key card. A lock that confirms the card is real, but not that it was cut for this room, opens every door in the corridor. The advisory describes a gap of that shape.
The advisory contrasts this with the library's token introspection example (RFC 7662). There, the client being checked is the caller, so a check on it is meaningful. In the RFC 7592 endpoint, the client is the target. The same style of code therefore looks like a safeguard but does not link the caller to the target.
What an attacker could do
The advisory says dynamic client registration under RFC 7591 is often run without an initial access token. The standard treats open self-service sign-up as normal. In that setup, an attacker can register a throwaway client and receive a valid token for free.
The attacker then sends that token to /register/ followed by a victim's client_id. The attacker must know or guess that client_id. The request succeeds if the victim passes the documented example's editable check, or whatever equivalent the developer built from it. The attacker can then read the full registration, change it or delete it.
The advisory gives redirect_uris as an example. Pointing it at an attacker-controlled address could allow interception of authorization codes or tokens for that client's users. The advisory also lists denial of service through deletion of client registrations. It rates the privileges required as low.
The lesson from this case: documentation can carry the flaw
In this case, the flaw sits in the example code rather than in the library's own logic. The advisory says no file in the repository offers a full, correct version of this endpoint. That includes the Flask, Django and SQLAlchemy modules. The docstrings were the only guidance.
The advisory does not say how many deployments copied the examples. That number is unknown. Teams that wrote their own binding check fall outside the scenario it describes.
The advisory also does not say what the 1.9.1 patch changes. It recommends fixing the docs and adding a warning. It does not say whether 1.9.1 does that. Moving to 1.9.1 may help, but the advisory does not confirm it. It cannot rewrite code a team already pasted into its own project.
Questions to put to your team
Ask whether any system you run uses Authlib's ClientConfigurationEndpoint, and which version is installed. If it is 1.7.2, ask what 1.9.1 changes before relying on it.
Ask to see the team's authenticate_client and check_permission methods. The test is simple: does either one compare the presented token's client with the target client_id?
The advisory's suggested fix is the same comparison. The code should confirm that the authenticated token belongs to the client being accessed.
Ask whether dynamic registration is open without an initial access token. The advisory says that setting is what makes the token free for an attacker.
Ask someone to review the redirect addresses on registered clients for changes nobody can explain.
A check that looks like authorization needs a test that proves it compares the right two things.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
