Live › vulnerability › CVE-2026-49272
Go to dashboardOAuthLib's RFC 8628 device-code grant does not check the device_code parameter at the token endpoint. An attacker who knows a client ID enabled for the device workflow can request a bearer token without a valid device code.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 13:31 UTC. All times on this page are UTC.
Applications that use oauthlib 3.3.0 up to 4.0.0 and enable the RFC 8628 device authorization grant on a token endpoint are exposed. The flaw needs a client ID that is enabled for the device workflow, and the sources say nothing more about the client types required beyond a public client in the proof of concept. Services that do not use the device-code grant can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| oauthlib | pypi | >= 3.3.0, < 4.0.0 | 4.0.0 |
pip show oauthlib and look for a version from 3.3.0 up to but not including 4.0.0.DeviceCodeGrant or device_code to see whether the device-code grant is enabled on a token endpoint.oauthlib to 4.0.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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 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 and here.
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.
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.
Anyone using the RFC 8628 device workflow in oauthlib that doesn't realize the device_code parameter is not being validated.
This page as .md · .json · in your agent: get_signal("CVE-2026-49272")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.