Summary
OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow
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 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.
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.
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
CVE-2026-49272 has a CVSS score of 8.5 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-49272? CVE-2026-49272 is a high-severity improper authentication vulnerability in oauthlib (pip), affecting versions >= 3.3.0, < 4.0.0. It is fixed in 4.0.0. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is CVE-2026-49272? CVE-2026-49272 has a CVSS score of 8.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of oauthlib are affected by CVE-2026-49272? oauthlib (pip) versions >= 3.3.0, < 4.0.0 is affected.
- Is there a fix for CVE-2026-49272? Yes. CVE-2026-49272 is fixed in 4.0.0. Upgrade to this version or later.
- Is CVE-2026-49272 exploitable, and should I be worried? Whether CVE-2026-49272 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-49272 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-49272? Upgrade
oauthlibto 4.0.0 or later.