{"id":"CVE-2026-49272","aliases":["DEBIAN-CVE-2026-49272","EUVD-2026-117800","GHSA-3jp2-3mrg-2vxc","ROOT-APP-PYPI-CVE-2026-49272","UBUNTU-CVE-2026-49272"],"status":"published","title":"OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow","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.","severity":{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00328,"percentile":0.26137,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-287"],"published":"2026-10-27T13:30:17Z","modified":"2026-11-07T01:46:17Z","fixes":[{"ecosystem":"PyPI","package":"oauthlib","fixed_in":["4.0.1"],"sources":["ghsa","osv"]},{"ecosystem":"Root:PyPI","package":"oauthlib","fixed_in":["3.3.1+aikido.1","3.3.1+aikido.2"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"4.0.1"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.2.2-1","3.2.2-2","3.2.2-3","3.2.2-4","3.3.1-1","3.3.1-2"]},{"source":"osv","ecosystem":"Debian:13","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.2.2-3","3.2.2-4","3.3.1-1","3.3.1-2"]},{"source":"osv","ecosystem":"Debian:14","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.2.2-3","3.2.2-4","3.3.1-1","3.3.1-2"]},{"source":"osv","ecosystem":"PyPI","package":"oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"4.0.1"}]}],"versions":["3.3.0","3.3.1","4.0.0"]},{"source":"osv","ecosystem":"Root:PyPI","package":"oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.3.1+aikido.1"},{"fixed":"3.3.1+aikido.2"}]}]},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.0.0-1","1.0.3-1"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.0.1-1","2.0.4-1","2.0.6-1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.1.0-1","3.1.0-1ubuntu1","3.1.0-1ubuntu2"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.1.0-2","3.1.1-1","3.2.0-1","3.2.0-1ubuntu0.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.2.2-1"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.3.1-1build1","3.3.1-2"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"python-oauthlib","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.2.2-3","3.3.1-1","3.3.1-1build1"]}],"products":[{"vendor":"oauthlib","product":"oauthlib"}],"references":[{"url":"https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3jp2-3mrg-2vxc","tags":["x_refsource_CONFIRM","exploit","advisory","web","report"]},{"url":"https://github.com/oauthlib/oauthlib/pull/954","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/oauthlib/oauthlib/commit/77a5f1c8ce00da2b0b8c5f6e9cc129920085f114","tags":["x_refsource_MISC","fix","web","report"]},{"url":"https://github.com/oauthlib/oauthlib/releases/tag/v4.0.1","tags":["x_refsource_MISC","web","report"]},{"url":"https://github.com/advisories/GHSA-3jp2-3mrg-2vxc"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/49xxx/CVE-2026-49272.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-49272","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-49272","tags":["advisory"]},{"url":"https://github.com/oauthlib/oauthlib","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-49272","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-49272","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-49272","title":"OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow","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.","status":"published","published":"2026-11-05T20:58:00.517Z","modified":"2026-11-05T21:14:43.982Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-287"],"updated_at":"2026-11-05T22:55:20.139479Z"}],"euvd":[{"id":"EUVD-2026-117800","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.","status":"published","published":"2026-11-05T20:58:00Z","modified":"2026-11-05T21:14:43Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high"}],"updated_at":"2026-11-05T23:02:21.997716Z"}],"ghsa":[{"id":"GHSA-3jp2-3mrg-2vxc","title":"OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow","description":"### Summary\nA 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.\n\n### Details\n\n[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).\n\nI 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`.\n\n### PoC\nCreate 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).\n\nCreate a client that has a `client_type` of `\"public\"` and set it's `grant_type` to `\"urn:ietf:params:oauth:grant-type:device_code\"`.\n\nWith this implementation of `RequestValidation.authenticate_client` done, use that validator for your token endpoint. Call the token endpoint with a body of \n```\n{\n  \"client_id\": \u003cID of the public client you made\u003e,\n  \"grant_type\": \"urn:ietf:params:oauth:grant-type:device_code\",\n  \"device_code\": \u003canything you want since it's not validated\u003e\n}\n```\n\nYou now have a bearer token for the client without a valid `device_code`.\n\n\n### Impact\nAnyone using the RFC 8628 device workflow in oauthlib that doesn't realize the `device_code` parameter is not being validated.","status":"published","published":"2026-10-27T13:30:17Z","modified":"2026-11-05T20:58:34Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high"}],"cwes":["CWE-287"],"updated_at":"2026-11-05T21:26:24.786879Z"}],"nvd":[{"id":"CVE-2026-49272","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.","status":"published","published":"2026-11-05T21:18:50.447Z","modified":"2026-11-05T22:18:44.593Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-287"],"updated_at":"2026-11-05T23:57:23.655479Z"}],"osv":[{"id":"CVE-2026-49272","title":"OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow","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.","status":"published","published":"2026-11-05T20:58:00.517Z","modified":"2026-11-07T02:48:35.448581292Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high"}],"cwes":["CWE-287"],"updated_at":"2026-11-07T03:08:06.526027Z"},{"id":"DEBIAN-CVE-2026-49272","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.","status":"published","published":"2026-11-05T21:18:50.447Z","modified":"2026-11-06T18:00:07.314060872Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high"}],"updated_at":"2026-11-06T18:35:17.269535Z"},{"id":"GHSA-3jp2-3mrg-2vxc","title":"OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow","description":"### Summary\nA 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.\n\n### Details\n\n[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).\n\nI 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`.\n\n### PoC\nCreate 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).\n\nCreate a client that has a `client_type` of `\"public\"` and set it's `grant_type` to `\"urn:ietf:params:oauth:grant-type:device_code\"`.\n\nWith this implementation of `RequestValidation.authenticate_client` done, use that validator for your token endpoint. Call the token endpoint with a body of \n```\n{\n  \"client_id\": \u003cID of the public client you made\u003e,\n  \"grant_type\": \"urn:ietf:params:oauth:grant-type:device_code\",\n  \"device_code\": \u003canything you want since it's not validated\u003e\n}\n```\n\nYou now have a bearer token for the client without a valid `device_code`.\n\n\n### Impact\nAnyone using the RFC 8628 device workflow in oauthlib that doesn't realize the `device_code` parameter is not being validated.","status":"published","published":"2026-10-27T13:30:17Z","modified":"2026-11-05T21:15:09.240948711Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high"}],"cwes":["CWE-287"],"updated_at":"2026-11-05T21:29:52.663034Z"},{"id":"UBUNTU-CVE-2026-49272","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.","status":"published","published":"2026-11-06T00:00:00Z","modified":"2026-11-07T01:46:17.442760075Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N","level":"high"}],"updated_at":"2026-11-07T01:56:47.245871Z"},{"id":"ROOT-APP-PYPI-CVE-2026-49272","title":"CVE-2026-49272 in oauthlib - Patched by Root","description":"Root has patched CVE-2026-49272 in the oauthlib package for Root:PyPI. Multiple fixed versions available.","status":"published","published":"2026-11-02T09:25:08Z","modified":"2026-11-02T10:15:03.279253809Z","updated_at":"2026-11-02T15:53:28.259095Z"}]}}