{"id":"GHSA-3jp2-3mrg-2vxc","summary":"OAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow","details":"### 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.","aliases":["CVE-2026-49272"],"modified":"2026-10-27T13:45:03.096035248Z","published":"2026-10-27T13:30:17Z","database_specific":{"cwe_ids":["CWE-287"],"severity":"HIGH","github_reviewed":true,"github_reviewed_at":"2026-10-27T13:30:17Z","nvd_published_at":null},"references":[{"type":"WEB","url":"https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3jp2-3mrg-2vxc"},{"type":"PACKAGE","url":"https://github.com/oauthlib/oauthlib"},{"type":"WEB","url":"https://github.com/oauthlib/oauthlib/releases/tag/v4.0.0"}],"affected":[{"package":{"name":"oauthlib","ecosystem":"PyPI","purl":"pkg:pypi/oauthlib"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.3.0"},{"fixed":"4.0.0"}]}],"versions":["3.3.0","3.3.1"],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-3jp2-3mrg-2vxc/GHSA-3jp2-3mrg-2vxc.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N"}]}