CVE-2026-49272: 
Python vulnerability analysis and mitigation

CVE-2026-49272 is an improper authentication vulnerability in the oauthlib Python library affecting the OAuth 2.0 Device Authorization Grant (RFC 8628) flow. The DeviceCodeGrant.validate_token_request method fails to validate the device_code parameter, allowing an attacker with knowledge of a valid client ID to obtain a bearer token using any arbitrary device_code value. It affects oauthlib versions >= 3.3.0 and < 4.0.0, and was published on October 23, 2026, with the advisory added to the GitHub Advisory Database on October 27, 2026. It carries a CVSS v3.1 base score of 8.5 (High) (GitHub Advisory).

The root cause is classified as CWE-287 (Improper Authentication). Per RFC 8628 Section 3.4, the token endpoint must validate the device_code parameter as a required input; however, DeviceCodeGrant.validate_token_request in oauthlib performs no such validation — neither checking for the parameter's presence nor its validity. By contrast, AuthorizationCodeGrant.validate_token_request correctly validates its equivalent code parameter. The fix introduces a new validate_device_code method in RequestValidator, analogous to validate_code, which is invoked during token request validation. The vulnerability is compounded by a related issue (#919) where DeviceCodeGrant.validate_token_request does not properly handle public clients, making exploitation easier in deployments using public client types (GitHub Advisory, oauthlib v4.0.0 Release).

Successful exploitation allows an authenticated attacker — one who knows a valid client ID configured for the device authorization workflow — to obtain a bearer token without a legitimate device authorization flow, effectively bypassing the device code verification step. This enables impersonation of device clients and unauthorized access to protected resources, with high integrity impact and limited confidentiality exposure (scope changed). Availability is not directly affected, but the ability to issue arbitrary tokens could facilitate further lateral movement or privilege escalation within systems relying on oauthlib for OAuth 2.0 enforcement (GitHub Advisory).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability requires low privileges (knowledge of a valid client ID) and no user interaction, making it relatively straightforward to exploit once a valid client ID is identified. No threat actor attribution has been reported, and the CVE status remains Reserved. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities catalog. No EPSS score is available at this time.

1. Reconnaissance: Identify a target application using oauthlib >= 3.3.0 with the Device Authorization Grant (urn:ietf:params:oauth:grant-type:device_code) enabled. Enumerate or discover a valid client_id configured for the device workflow (e.g., through API documentation, error messages, or prior access).
2. Confirm public client type: Verify or infer that the target client is configured as a public client type, which bypasses standard client secret authentication in the vulnerable DeviceCodeGrant.validate_token_request path.
3. Craft malicious token request: Send an HTTP POST request to the token endpoint with the following body:

client_id=<valid_client_id>&grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=<any_bogus_value>

4. Receive bearer token: Because DeviceCodeGrant.validate_token_request does not validate the device_code parameter, the server issues a valid bearer token without verifying that a legitimate device authorization flow was completed.
5. Access protected resources: Use the obtained bearer token in the Authorization: Bearer <token> header to access APIs or resources protected by the OAuth 2.0 server (GitHub Advisory).

• Network: Unexpected or repeated POST requests to the OAuth token endpoint with grant_type=urn:ietf:params:oauth:grant-type:device_code and device_code values that do not correspond to any initiated device authorization flow; requests originating from IPs not associated with known device clients.
• Logs: Token endpoint access logs showing successful token issuance for device code grant requests where no corresponding device authorization request was initiated; multiple token requests with varying device_code values from the same client_id.
• Application Behavior: Bearer tokens being used to access resources from unexpected IP addresses or user agents inconsistent with the device type associated with the client ID; token usage patterns that do not align with the expected device authorization lifecycle (e.g., no prior /device_authorization request).

Upgrade oauthlib to version 4.0.0, which introduces validate_device_code in RequestValidator and fixes client authentication handling for DeviceCodeGrant (PRs #919 and #920) (oauthlib v4.0.0 Release, GitHub Advisory). As a temporary workaround prior to patching, restrict access to the token endpoint and implement application-level validation of device_code values against a store of legitimately issued device codes before processing token requests. Additionally, audit all RequestValidator implementations to ensure authenticate_client does not unconditionally return True for public clients using the device grant type.

The advisory was published by oauthlib maintainer JonathanHuot on October 23, 2026, and credited to reporter hekhuisk who identified both the missing device_code validation and the related public client handling issue (#919). The fix was incorporated into the oauthlib 4.0.0 release alongside other breaking changes and security improvements (oauthlib v4.0.0 Release). No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified at this time.