CVE-2026-116672

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.

Description

Summary

RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol) lets a previously registered client read, update, or delete its own registration, authenticated by a registration_access_token issued specifically to that client at registration time. The entire security model of this protocol depends on the server verifying that the token presented in the request actually belongs to the client identified in the request, not merely that the token is valid for some client.

Authlib's ClientConfigurationEndpoint implements the control flow correctly in structure, calling authenticate_token, then authenticate_client, then check_permission, and treats all three as abstract methods that "Developers MUST implement in subclass." The problem is that the documented example implementations for these methods, taken together exactly as written, never perform the one check that matters: binding the authenticated token to the specific client being accessed. A developer who implements these methods by following the provided examples ends up with a complete authorization bypass on this endpoint.

Details

authenticate_client's documented example (authlib/oauth2/rfc7592/endpoint.py):

def authenticate_client(self, request):
    """Read a client from the request payload.
    Developers MUST implement this method in subclass::

        def authenticate_client(self, request):
            client_id = request.payload.data.get("client_id")
            return Client.get(client_id=client_id)

    :return: client instance
    """
    raise NotImplementedError()

This looks the target client up purely by the client_id supplied in the request payload, with no reference to the token at all.

check_permission's documented example, in the same file:

def check_permission(self, client, request):
    """Checks whether the current client is allowed to be accessed, edited
    or deleted. Developers MUST implement it in subclass, e.g.::

        def check_permission(self, client, request):
            return client.editable

    :return: boolean
    """
    raise NotImplementedError()

This checks a property of the target client alone (whether it is generally "editable"), again with no reference to request.credential, the authenticated token object returned earlier by authenticate_token and stored on the request specifically so that later steps can check it:

def create_configuration_response(self, request):
    token = self.authenticate_token(request)
    if not token:
        raise AccessDeniedError()

    request.credential = token

    client = self.authenticate_client(request)
    ...
    if not self.check_permission(client, request):
        raise UnauthorizedClientError(...)

request.credential is set specifically so that a binding check can be performed downstream, but neither documented example ever reads it. Following both examples as written produces an implementation where the only requirements to access, modify, or delete a client's registration are: possessing any valid registration_access_token for any client, and knowing or guessing the target client_id.

This is meaningfully different from how the equivalent example is written for the token introspection endpoint (RFC 7662) elsewhere in the same codebase, which does correctly demonstrate checking the authenticated caller's own identity (authlib/oauth2/rfc7662/introspection.py):

def check_permission(self, token, client, request):
    """Check if the request has permission to introspect the token. Developers
    MUST implement this method::

        def check_permission(self, token, client, request):
            # only allow a special client to introspect the token
            return client.client_id == "introspection_client"
    """

In that endpoint, client represents the already-authenticated caller (verified through normal client credential authentication earlier in the…

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.

Description

Summary

RFC 7592 (OAuth 2.0 Dynamic Client Registration Management Protocol) lets a previously registered client read, update, or delete its own registration, authenticated by a registration_access_token issued specifically to that client at registration time. The entire security model of this protocol depends on the server verifying that the token presented in the request actually belongs to the client identified in the request, not merely that the token is valid for some client.

Authlib's ClientConfigurationEndpoint implements the control flow correctly in structure, calling authenticate_token, then authenticate_client, then check_permission, and treats all three as abstract methods that "Developers MUST implement in subclass." The problem is that the documented example implementations for these methods, taken together exactly as written, never perform the one check that matters: binding the authenticated token to the specific client being accessed. A developer who implements these methods by following the provided examples ends up with a complete authorization bypass on this endpoint.

Details

authenticate_client's documented example (authlib/oauth2/rfc7592/endpoint.py):

def authenticate_client(self, request):
    """Read a client from the request payload.
    Developers MUST implement this method in subclass::

        def authenticate_client(self, request):
            client_id = request.payload.data.get("client_id")
            return Client.get(client_id=client_id)

    :return: client instance
    """
    raise NotImplementedError()

This looks the target client up purely by the client_id supplied in the request payload, with no reference to the token at all.

check_permission's documented example, in the same file:

def check_permission(self, client, request):
    """Checks whether the current client is allowed to be accessed, edited
    or deleted. Developers MUST implement it in subclass, e.g.::

        def check_permission(self, client, request):
            return client.editable

    :return: boolean
    """
    raise NotImplementedError()

This checks a property of the target client alone (whether it is generally "editable"), again with no reference to request.credential, the authenticated token object returned earlier by authenticate_token and stored on the request specifically so that later steps can check it:

def create_configuration_response(self, request):
    token = self.authenticate_token(request)
    if not token:
        raise AccessDeniedError()

    request.credential = token

    client = self.authenticate_client(request)
    ...
    if not self.check_permission(client, request):
        raise UnauthorizedClientError(...)

request.credential is set specifically so that a binding check can be performed downstream, but neither documented example ever reads it. Following both examples as written produces an implementation where the only requirements to access, modify, or delete a client's registration are: possessing any valid registration_access_token for any client, and knowing or guessing the target client_id.

This is meaningfully different from how the equivalent example is written for the token introspection endpoint (RFC 7662) elsewhere in the same codebase, which does correctly demonstrate checking the authenticated caller's own identity (authlib/oauth2/rfc7662/introspection.py):

def check_permission(self, token, client, request):
    """Check if the request has permission to introspect the token. Developers
    MUST implement this method::

        def check_permission(self, token, client, request):
            # only allow a special client to introspect the token
            return client.client_id == "introspection_client"
    """

In that endpoint, client represents the already-authenticated caller (verified through normal client credential authentication earlier in the…

Authlib is a Python library which builds OAuth and OpenID Connect servers. From 0.15 until 1.9.1, the documented ClientConfigurationEndpoint.authenticate_client and ClientConfigurationEndpoint.check_permission reference implementations look up a target client from request-controlled client_id data and check only whether that target is editable, without verifying that request.credential belongs to the target client. Deployments following both examples can allow a client holding any valid registration access token to read, modify, or delete another client's registration. Changing redirect_uris can enable authorization code or token interception, while deleting registrations can deny service to affected clients. This issue is fixed in version 1.9.1.

These are all security issues fixed in the python313-Authlib-1.9.1-1.1 package on the GA media of openSUSE Tumbleweed.