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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-11-05T21:18:50.447Z",
  "pubdate": "2026-11-05T21:18:50.447Z",
  "executiveSummary": "The OAuthLib library is susceptible to an authentication bypass vulnerability within its implementation of the RFC 8628 device authorization grant workflow.\nThe vulnerability originates from a failure in the DeviceCodeGrant.validate_token_request function to properly enforce the presence and validity of the mandatory device_code parameter.\nThis flaw allows a remote attacker possessing a valid client ID enabled for the device workflow to interact with the token endpoint without completing the mandated user authorization process.\nBy submitting a missing or arbitrary device_code, the attacker can successfully solicit a bearer token, effectively circumventing the intended security model of the device flow.\nThe vulnerability affects OAuthLib versions 3.3.0 through 4.0.0. The impact includes unauthorized access to resources granted via bearer tokens, potentially leading to full account takeover or unauthorized data access depending on the scope of the issued tokens.\nSuccessful exploitation requires the attacker to have knowledge of a valid client ID and the target system must be configured to use the affected device workflow implementation.",
  "technicalDetails": "The vulnerability exists within the OAuthLib library's implementation of the RFC 8628 (OAuth 2.0 Device Authorization Grant). Specifically, the core issue resides in the DeviceCodeGrant.validate_token_request method, which serves as the validation gatekeeper for token issuance requests.\nIn the affected versions (3.3.0 to 4.0.0), the library fails to verify the presence and the cryptographically signed validity of the device_code parameter during the request validation phase. In a standard RFC 8628 flow, the device_code is an opaque, short-lived identifier that must be verified against the authorization server's database to ensure the user has actually granted consent via the browser-based authorization step.\nThe attack flow proceeds as follows: 1) An attacker identifies a client ID authorized to use the device workflow. 2) The attacker crafts a request to the token endpoint using the OAuth 2.0 protocol. 3) Because the DeviceCodeGrant.validate_token_request function does not perform a strict check for the existence of the device_code or its correlation with a legitimate authorization session, the validator incorrectly considers the request valid if other parameters (like client_id and grant_type) are satisfied by the configuration. 4) The application logic proceeds to generate and issue a bearer token despite the absence of the verified authorization state. 5) The attacker receives the bearer token, granting them immediate, unauthorized access to the client’s resources or API scope.\nThis vulnerability effectively reduces the security of the device authorization flow to the knowledge of a client ID, stripping away the requirement for a user-mediated consent process. Because the check is skipped in the server-side code, the server treats the request as if the device code has been successfully verified, bypassing the protocol's primary security control for device authentication. The impact is critical as it permits the automated acquisition of bearer tokens, which can be leveraged for unauthorized resource consumption or data exfiltration. The exploitation is remote and does not require elevated privileges beyond the ability to submit requests to the token endpoint, provided the client ID is known."
}