CVE-2026-49272: 
Python Análise e mitigação de vulnerabilidades

CVE-2026-49272 is an improper authentication vulnerability in the OAuthLib Python library affecting the OAuth 2.0 device authorization grant flow (RFC 8628). The DeviceCodeGrant.validate_token_request method fails to validate the device_code parameter, allowing an attacker with knowledge of a valid client ID enabled for the device workflow to obtain a bearer token using a fabricated device_code. Affected versions are oauthlib >= 3.3.0 (pip), with the fix released in version 4.0.0/4.0.1. It carries a CVSS v3.1 base score of 8.5 (High) (GitHub Advisory, oauthlib 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 that device_code is present nor that it corresponds to a previously issued code. This contrasts with AuthorizationCodeGrant.validate_token_request, which properly validates the authorization code. The attack is network-accessible, requires low privileges (a valid client ID for a public client enabled for device flow), and no user interaction. A compounding issue in DeviceCodeGrant.validate_token_request related to improper handling of public clients (tracked as oauthlib issue #919) further enables exploitation (GitHub Advisory, oauthlib Advisory).

Successful exploitation allows an authenticated user (with knowledge of a valid client ID) to bypass device code validation entirely and obtain a valid bearer token without completing the device authorization flow. This enables unauthorized access to protected resources, token impersonation, and potential session hijacking across any system relying on oauthlib's device flow implementation. The scope change in the CVSS score reflects that the impact extends beyond the vulnerable component itself to downstream protected resources (GitHub Advisory).

A proof-of-concept (PoC) with step-by-step reproduction instructions is publicly available in the GitHub Security Advisory, including the exact HTTP request body needed to trigger the bypass. Feedly threat intelligence classifies the PoC confidence as high, noting it contains concrete parameters and payload structure. There is no evidence of in-the-wild exploitation at this time, and the CVE is not listed in the CISA KEV catalog. No EPSS score is currently available as the CVE status remains "Reserved" (GitHub Advisory, oauthlib Advisory).

1. Reconnaissance: Identify applications using oauthlib >= 3.3.0 with the OAuth 2.0 device authorization grant flow (RFC 8628) enabled. Enumerate or discover a valid client_id that is configured for the device workflow (e.g., through public API documentation, error messages, or prior access).
2. Identify public client: Confirm the target client has client_type set to "public", which causes authenticate_client to return True without requiring a client secret, enabling the bypass 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_arbitrary_value>

4. Obtain bearer token: Because DeviceCodeGrant.validate_token_request does not validate the device_code parameter, the server issues a valid bearer token without verifying that the device code was legitimately issued or approved.
5. Access protected resources: Use the obtained bearer token in the Authorization: Bearer <token> header to access any resources the client is authorized for, effectively impersonating a legitimately authorized device (GitHub Advisory, oauthlib Advisory).

• Network: Unexpected 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 match any previously issued device authorization codes; high volume of such requests from a single IP or client ID.
• Logs: Token endpoint access logs showing successful bearer token issuance for device flow requests where no corresponding device authorization request was initiated; repeated token issuance for the same client_id with varying device_code values.
• Application Behavior: Bearer tokens being used to access protected resources from IP addresses or user agents inconsistent with expected device flow clients; tokens issued outside of expected device authorization sessions.

Upgrade oauthlib to version 4.0.0 or later (pip package), which includes the fix for client authentication in DeviceCodeGrant (PR #920) and reorganizes client authentication validation across grants. The fix adds proper device_code validation within DeviceCodeGrant.validate_token_request, analogous to how AuthorizationCodeGrant validates authorization codes. As an interim workaround if immediate upgrade is not possible, consider temporarily disabling the device flow grant type, or implementing custom server-side validation of device_code parameters in the token endpoint to ensure they match previously issued codes. Audit existing bearer tokens issued through device flow to identify potential unauthorized access (oauthlib Release, oauthlib Advisory).

The vulnerability was reported by researcher hekhuisk and published by oauthlib maintainer JonathanHuot on October 23, 2026. The fix was incorporated into the oauthlib 4.0.0 release, which the maintainer described as a foundational release enabling AI-assisted contributions and maintenance improvements. No significant broader media coverage or notable community debate has been identified beyond the advisory and standard vulnerability tracking (oauthlib Release, GitHub Advisory).