CVE-2026-118669 in OAuthLib
Summary
by MITRE • 10/28/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified within OAuthLib prior to version 4.0.0 represents a critical logic flaw in the handling of client authentication and grant validation during token issuance processes. Specifically, this defect affects two distinct OAuth2 grant types: Client Credentials and Resource Owner Password Credentials. In these flows, the library's internal mechanisms for authenticating the request object contain an inconsistency where the authenticated client identity is decoupled from the client identifier provided in the request payload. This architectural weakness allows a scenario where the server successfully authenticates one confidential client but retains an attacker-supplied or manipulated client_id value within the request context used for subsequent authorization checks.
The core technical flaw lies in how the validate_grant_type and validate_scopes methods interact with the authenticated state of the request object. When these validation functions are invoked, they may rely on the raw client_id argument supplied by the requester rather than strictly enforcing the identity established during the authentication phase via request.client. This discrepancy creates a privilege escalation vector where an attacker who has obtained valid credentials for a lower-privilege or less capable authenticated client can inject a different client_id into their token request. If the application's validator logic prioritizes this injected client_id over the verified session context, the authorization engine may erroneously grant permissions associated with the target high-privilege client rather than the actual authenticating entity.
The operational impact of this vulnerability is significant for applications that implement custom or third-party validators which do not strictly enforce consistency between authentication and authorization contexts. An attacker can exploit this to obtain access tokens that carry unauthorized grants or scopes belonging to a more privileged service account or application. This effectively bypasses the intended isolation boundaries between different OAuth clients, potentially leading to data exfiltration, unauthorized administrative actions, or further lateral movement within an identity infrastructure. The severity is heightened in environments where scope validation relies heavily on the client_id parameter rather than the authenticated principal's actual capabilities as determined by the authentication backend.
Mitigation strategies must address both the library version and the application-level validator logic. The primary remediation is to upgrade OAuthLib to version 4.0.0 or later, which resolves this inconsistency by ensuring that grant and scope authorization strictly adhere to the identity established during client authentication. For applications unable to immediately update their dependencies, developers should audit their custom validators to ensure they exclusively authorize access based on request.client rather than relying solely on the raw client_id argument from the request payload. Implementing strict validation checks that compare the authenticated client against any provided identifiers can also serve as a defensive control until the library is updated.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where an actor obtains privileges it should not have due to flawed logic in access control decisions. Furthermore, from a threat modeling perspective consistent with MITRE ATT&CK techniques, this flaw facilitates lateral movement and privilege escalation within the OAuth ecosystem by allowing lower-privilege accounts to masquerade as higher-privilege entities during token acquisition. Understanding these mappings helps security teams prioritize remediation efforts based on standard industry frameworks for vulnerability classification and attack path analysis.