Answer in brief
CVE-2026-49272 records a High severity (CVSS 8.5) vulnerability in OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow. The current sources do not mark it as known exploited. The current feed maps oauthlib (pip), oauthlib (pypi). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps oauthlib (pip), oauthlib (pypi). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| oauthlibpip | >=3.3.0,<4.0.0 | 4.0.0 |
| oauthlibpypi | >=3.3.0 <4.0.0 | 4.0.0 |
Published upstream
Oct 27, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Oct 27, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Oct 27, 2026
### 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.
Quoted source text, attributed separately from HOL analysis.