CVE-2026-49272High· 8.5▾ TwilightOAuthLib: Bearer token can be retrieved as long as client knows a valid client ID for device workflow
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 46.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
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.
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.
Anyone using the RFC 8628 device workflow in oauthlib that doesn't realize the device_code parameter is not being validated.
oauthlib >= 3.3.0, < 4.0.0Upgrade to a patched release:
oauthlib 4.0.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-49264Medium· 6.1OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+
CVE-2026-49265Medium· 6.8OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+
CVE-2024-47533Critical· 9.8cobbler allows anyone to connect to cobbler XML-RPC server with known password and make changes
CVE-2026-100169High· 7.6Improper Authentication in the social account linking path of the Prowler API in Prowler from 5.4.0 before 5.35.0 allows a remote unauthenticated attacker to obtain persistent access to the account of a user who has not yet registered, b…
CVE-2024-25128Critical· 9.1Flask-AppBuilder vulnerable to incorrect authentication when using auth type OpenID
CVE-2023-49105Critical· 9.8An issue was discovered in ownCloud owncloud/core before 10.13.1