Affected: Homebrew: ansible

## Summary

OAuthlib's token grant handlers can authenticate one client while authorizing the grant type and requested scopes using a different, attacker-supplied `client_id` from the request body.

In affected token grant flows, `authenticate_client(request)` sets `request.client` to the authenticated client object, but OAuthlib does not require `request.client_id` to match `request.client.client_id`. If the request body already contains `client_id=...`, OAuthlib keeps that value and passes it to `validate_grant_type()` and `validate_scopes()`.

As a result, an authenticated low-privilege confidential client can authenticate as itself, submit another client's `client_id` in the token request body, and cause grant and scope validation to run under that other client identity.

## Affected Surface

The affected public surface is the OAuth2 token endpoint handling for:

- `client_credentials` - `password` / Resource Owner Password Credentials

The issue is relevant to OAuthlib provider deployments where:

- the attacker has credentials for one valid lower-privilege confidential client; - another client has broader grants or scopes; - the application validator uses the `client_id` argument passed by OAuthlib in `validate_grant_type()` or `validate_scopes()`, as the `RequestValidator` API is designed to support.

Deployments whose validators ignore the `client_id` argument and authorize only from `request.client` may not be affected.

## Details

`Request` parses query and body p…

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. Prior to 4.0.0, the client_credentials and Resource Owner Password Credentials token grant handlers can authenticate request.client as one confidential client while retaining an attacker-supplied request.client_id for validate_grant_type and validate_scopes. A lower-privilege authenticated client can therefore cause grant and scope authorization to use another client's identity when an application validator relies on the documented client_id argument, potentially issuing tokens with unauthorized grants or scopes. Validators that authorize exclusively from request.client may not be affected. This issue is fixed in version 4.0.0.

Affected: PyPI: oauthlib

## Summary

OAuthlib's token grant handlers can authenticate one client while authorizing the grant type and requested scopes using a different, attacker-supplied `client_id` from the request body.

In affected token grant flows, `authenticate_client(request)` sets `request.client` to the authenticated client object, but OAuthlib does not require `request.client_id` to match `request.client.client_id`. If the request body already contains `client_id=...`, OAuthlib keeps that value and passes it to `validate_grant_type()` and `validate_scopes()`.

As a result, an authenticated low-privilege confidential client can authenticate as itself, submit another client's `client_id` in the token request body, and cause grant and scope validation to run under that other client identity.

## Affected Surface

The affected public surface is the OAuth2 token endpoint handling for:

- `client_credentials` - `password` / Resource Owner Password Credentials

The issue is relevant to OAuthlib provider deployments where:

- the attacker has credentials for one valid lower-privilege confidential client; - another client has broader grants or scopes; - the application validator uses the `client_id` argument passed by OAuthlib in `validate_grant_type()` or `validate_scopes()`, as the `RequestValidator` API is designed to support.

Deployments whose validators ignore the `client_id` argument and authorize only from `request.client` may not be affected.

## Details

`Request` parses query and body p…

libcurl: libcurl: Security feature bypass due to improper mTLS connection reuse python: python: Arbitrary file deletion via race condition during temporary directory cleanup python: Use-after-free of a server-side SSLContext when sni_callback switches contexts python: python: Certificate verification bypass via missing server_hostname validation in SSLContext.wrap_bio() xz: XZ Utils: Denial of Service via buffer overflow in index decoding openssh: OpenSSH: SFTP security bypass due to command-line argument parsing flaw openssh: OpenSSH: Undocumented GSSAPIStrictAcceptorCheck behavior impacts security in Windows Active Directory openssh: OpenSSH: Denial of Service via excessive GSSAPI authentication attempts expat: expat: Information disclosure via heap buffer over-read in XML_ParseBuffer libX11: libX11: Heap-based buffer overflow via malicious X server urllib3: urllib3: Traffic interception via HTTPS proxy TLS configuration override urllib3: urllib3: Denial of Service via unbounded memory allocation in chunk parser expat: expat: Denial of Service via integer overflow in expat_realloc brotli: Out-of-Bounds Write in Google Brotli Decoder djangorestframework: djangorestframework: Denial of Service via improper charset handling in JSON parser djangorestframework: djangorestframework: Unauthorized access via improper token revocation in TokenProxy djangorestframework: djangorestframework: Denial of Service via unbounded Accept header parsing ca-certificates: Distrust eMudhra inter…

Affected: Ubuntu:16.04:LTS: python-oauthlib, Ubuntu:18.04:LTS: python-oauthlib, Ubuntu:20.04:LTS: python-oauthlib, Ubuntu:22.04:LTS: python-oauthlib, Ubuntu:24.04:LTS: python-oauthlib, Ubuntu:26.10: python-oauthlib, Ubuntu:26.04:LTS: python-oauthlib

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. Prior to 4.0.0, the client_credentials and Resource Owner Password Credentials token grant handlers can authenticate request.client as one confidential client while retaining an attacker-supplied request.client_id for validate_grant_type and validate_scopes. A lower-privilege authenticated client can therefore cause grant and scope authorization to use another client's identity when an application validator relies on the documented client_id argument, potentially issuing tokens with unauthorized grants or scopes. Validators that authorize exclusively from request.client may not be affected. This issue is fixed in version 4.0.0.