Patch Forecast
Yellow warning
Plan into this sprint.

CVE-2026-49272 · GHSA-3jp2-3mrg-2vxc

OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow

Risk score
56/100
CVSS
8.5 v3.1
Published
27 Oct 2026

Open in the live forecast Today's forecast

What to know

What it is
A call to the token endpoint with a grant type of "urn:ietf:params:oauth:grant-type:device_code" and a bogus device_code is able to get a bearer token as long as they know a valid client ID enabled for the device workflow. Section 3.4 of the RFC 8628 spec says that the token endpoint should take in device_code as a re…
Affected
oauthlib (pip) >= 3.3.0, < 4.0.0
Fix
Upgrade oauthlib to 4.0.0 or later.
Exploitation
No known exploitation

Story map

Story map: oauthlibTHE FLAWSTHE FIXCVE-2026-49272OAuthLib: Bearer token can beretrieved as long as clientknows a valid client ID for…CVSS 8.5CVE-2026-49265Oauthlib: Timing AttackVulnerability in PKCEcode_verifier Comparison…CVSS 6.8 · EPSS 0%CVE-2026-49264Oauthlib : Unsafe JSONPcallback injection inRevocationEndpoint allows…CVSS 6.1 · EPSS 0%Upgrade oauthlib4.0.0or later on your release lineWho is exposedoauthlib (pip) >= 3.3.0, < 4.0.0YELLOW · PLAN IT INoauthlibA call to the token endpoint witha grant type of"urn:ietf:params:oauth:grant-type:device_code" and a bogusdevice_code is able to get abearer token as long as theyknow a valid client ID enabled…Where it standsPublic proof of conceptCONNECTS TOSame weaknessAuthentication bypass (CWE-287)249 other warnings in 30 days →
Story map: the flaws, the fix, how it unfolded and what it connects to. Boxes link to the record or article.

At a glance

oauthlib: Yellow, plan it in. A call to the token endpoint with a grant type of "urn:ietf:params:oauth:grant-type:device_code" and a bogus device_code is able to get a bearer token as long as they know a valid client ID enabled for the device workflow. Section 3.4 of the RFC 8628 spec says that the token endpoint should take in device_code as a re…

The flaws

  • CVE-2026-49272: OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow (CVSS 8.5)
  • CVE-2026-49265: Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (CWE-208) (CVSS 6.8 · EPSS 0%)
  • CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (CVSS 6.1 · EPSS 0%)

The fix

Upgrade oauthlib: 4.0.0 or later on your release line

Who is exposed: oauthlib (pip) >= 3.3.0, < 4.0.0

Where it stands

  • Public proof of concept

Connects to

Why it is Yellow

  • CVSS 8.5 high
  • On your watchlist: PyPI

Affected packages

PackageEcosystemVulnerableFixed in
oauthlibpip>= 3.3.0, < 4.0.04.0.0

References

Original description

### Summary A call to the token endpoint with a grant type of `"urn:ietf:params:oauth:grant-type:device_code"` and a bogus `device_code` is able to get a bearer token as long as they know a valid client ID enabled for the device workflow. ### Details [Section 3.4 of the RFC 8628 spec](https://datatracker.ietf.org/doc/html/rfc8628#section-3.4) says that the token endpoint should take in `device_code` as a required parameter.`DeviceCodeGrant.validate_token_request` does not perform any validation of `device_code`. `DeviceCodeGrant.validate_token_request` should be validating that `device_code` was passed in as a parameter and that it is valid, similar to how `AuthorizationCodeGrant.validate_token_request` does the checks [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L446) and [here](https://github.com/oauthlib/oauthlib/blob/a015b446622f2b925517501fe484c10eff7a83c0/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L483). I would like to propose a new method be added to `RequestValidator` called `validate_device_code` that is similar to the `validate_code` method and is called inside of `DeviceCodeGrant.validate_token_request`. ### PoC Create an implementation of `RequestValidation.authenticate_client` that returns `True` if the client's `client_type` is `"public"`. You would find yourself in this scenario because there's another issue with `DeviceCodeGrant.validate_token_request` where it doesn't properly handle public clients (see https://github.com/oauthlib/oauthlib/issues/919). Create a client that has a `client_type` of `"public"` and set it's `grant_type` to `"urn:ietf:params:oauth:grant-type:device_code"`. With this implementation of `RequestValidation.authenticate_client` done, use that validator for your token endpoint. Call the token endpoint with a body of ``` { "client_id": <ID of the public client you made>, "grant_type": "urn:ietf:params:oauth:grant-type:device_code", "device_code": <anything you want since it's not validated> } ``` You now have a bearer token for the client without a valid `device_code`. ### Impact Anyone using the RFC 8628 device workflow in oauthlib that doesn't realize the `device_code` parameter is not being validated.

Last activity 27 Oct 2026. Patch Forecast updates every hour.