OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow
- Exploited
- Proof of concept public, per CISA
- Fix
- Fixed in 4.0.1
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Uses the RFC 8628 device workflow (DeviceCodeGrant) in oauthlib The configured RequestValidator authenticate_client accepts the client (e.g. a public client) Attacker knows a valid client ID enabled for the device workflow
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 52/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: no
- Technical impact: partial
Summary
OAuthLib, a Python library for OAuth request signing, lets an attacker obtain a bearer token without completing device authorization by submitting a missing or invalid device code to the token endpoint. The attacker reaches it remotely after logging in with low privileges, and needs only a valid client ID enabled for the device workflow.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 3.3.0 until 4.0.1, OAuthLib's RFC 8628 device workflow does not require DeviceCodeGrant.validate_token_request to check that the device_code parameter is present and valid. A caller whose client request is accepted by the configured validator and who knows a valid client ID enabled for the device workflow can submit a missing or bogus device code to the token endpoint and obtain a bearer token without completing device authorization. This issue is fixed in version 4.0.1.
cve.now Index
- Exploitation15/40CISA rates a proof of concept as public
- Exposure8/25Specific setups only, reachable over the network
- Reach20/20oauthlib: 64.2M downloads a week
- Severity8.5/10CVSS 8.5
- No patch0/5No signal
What would change the score
- Would score about 87 if added to CISA KEV
- Would score about 82 if CISA's SSVC rates exploitation active
- Would score about 59 if CISA's SSVC rates it automatable
Impact
- Widely used
oauthlib has 64.2m weekly downloads.Source: pypistats.org
13.6k packages depend on oauthlib.Source: deps.dev
What to do
Check whether your setup matches what the bug needs.
Uses the RFC 8628 device workflow (DeviceCodeGrant) in oauthlib The configured RequestValidator authenticate_client accepts the client (e.g. a public client) Attacker knows a valid client ID enabled for the device workflowUpgrade to a fixed version: 4.0.1.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: poc · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- oauthlib oauthlib
From 3.3.0 · fixed in 4.0.1
- oauthlibPyPI
From 3.3.0 · fixed in 4.0.0
Evidence 4
- Advisory
- Repository
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-49272
Is CVE-2026-49272 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. CISA's SSVC assessment notes a proof of concept exists. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
In oauthlib's RFC 8628 device workflow (DeviceCodeGrant), the token endpoint does not check the device_code parameter. A client that knows a valid client ID enabled for the device workflow can submit a missing or bogus device_code and receive a bearer token without completing device authorization.Source: github.com
Which versions are affected by CVE-2026-49272?
oauthlib: from 3.3.0 before 4.0.1. oauthlib (PyPI): from 3.3.0 before 4.0.0.Source: cve.now feed data
Am I affected, and how do I check?
The product records list oauthlib from 3.3.0 up to a fix in 4.0.0 or 4.0.1, depending on the record. The issue applies only where the device workflow is used and the configured RequestValidator authenticate_client accepts the client, such as a public client. To check, look at the installed oauthlib version (for example with pip show oauthlib) and whether the application uses DeviceCodeGrant.Source: github.com
How do I fix CVE-2026-49272?
Upgrade oauthlib to 4.0.1, the later fixed version listed in the product records. If the device workflow is not needed, it can be turned off in the application.Source: github.com