ZDF
Sign inSign up

Vulnerabilities

Vulnerability · CVE-2026-49272

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

Published Oct 27, 2026 · catalog updated Nov 5, 2026 · Red Hat Red Hat Enterprise Linux

Last checked Nov 8, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-49272. EPSS is 0.33%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.

Gaps on this record

  • No vendor fix or required action is stored. Compare the linked advisory before you change production.

Same product and reporting

Severity
High8.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.33%
Remediation
Advisory link
Affected products
PyPI oauthlib · pypi oauthlib

### Summary A call to the token endpoint with a grant type of and a bogus 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 as a required parameter. does not perform any validation of . should be validating that was passed in as a parameter and that it is valid, similar to how 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 called that is similar to the method and is called inside of . ### PoC Create an implementation of that returns if the client's is . You would find yourself in this scenario because there's another issue with where it doesn't properly handle public clients (see https://github.com/oauthlib/oauthlib/issues/919). Create a client that has a of and set it's to . With this implementation of done, use that validator for your token endpoint. Call the token endpoint with a body of You now have a bearer token for the client without a valid . ### Impact Anyone using the RFC 8628 device workflow in oauthlib that doesn't realize the parameter is not being validated.

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • PyPI oauthlib3.3.0 → 4.0.1
  • pypi oauthlibversion unspecified

How to fix CVE-2026-49272

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-49272. EPSS is 0.33%. Act only if a listed version of Red Hat Red Hat Enterprise Linux is installed.

Which versions are affected?

Compare what you have installed with 3.3.0 → 4.0.1. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-287: Improper Authentication; CWE-303. EPSS 0.33%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 27, 2026 · GitLab Advisory Database

    Detected

    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.

  2. Nov 5, 2026 · GitHub Advisory Database

    Fix available

    oauthlib fixed in 4.0.1

  3. Nov 5, 2026 · GitHub Advisory Database

    Fix available

    oauthlib fixed in 4.0.1

  4. Nov 5, 2026 · GitHub Advisory Database

    Updated

    ### Summary A call to the token endpoint with a grant type of and a bogus 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 as a required parameter. does not perform any validation of . should be va

Sources

  • CVE.orgVulnerability recordCVE-2026-49272

    Official CVE identifier

    cve.org
  • FIRST EPSSExploitation probabilityCVE-2026-49272

    30-day exploitation probability 0.33%

    first.org
  • GitHub Advisory DatabasePackage advisoryGHSA-3jp2-3mrg-2vxc

    GitHub Advisory Database record mirrored by OSV.

    github.com
  • GitLab Advisory DatabasePackage advisoryCVE-2026-49272

    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.

    advisories.gitlab.com
  • OpenSSF OSV / OSV ScannerPackage advisoryGHSA-3jp2-3mrg-2vxc

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

    osv.dev
  • PyPA Advisory DatabasePackage advisoryGHSA-3jp2-3mrg-2vxc

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

    osv.dev
  • Red Hat Security DataVendor advisoryCVE-2026-49272

    oauthlib: oauthlib: Authentication bypass via missing device code validation

    access.redhat.com

References

Freshness

Last verified in this catalog Nov 6, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.

  • Red Hat Security DataNov 8, 2026
  • PyPA Advisory DatabaseNov 7, 2026
  • FIRST EPSSNov 6, 2026
  • GitHub Advisory DatabaseNov 6, 2026
  • OpenSSF OSV / OSV ScannerNov 6, 2026
  • CVE.orgOct 28, 2026
  • GitLab Advisory DatabaseOct 28, 2026