Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
OAuthlib's token grant handlers can authenticate one client while authorizing the grant type and requested scopes using a different, attacker-supplied `client_id` from the request body. In affected token grant flows, `authenticate_client(request)` sets `request.client` to the authenticated client object, but OAuthlib does not require `request.client_id` to match `request.client.client_id`. If the request body already contains `client_id=...`, OAuthlib keeps that value and passes it to `validate_grant_type()` and `validate_scopes()`. As a result, an authenticated low-privilege confidential client can authenticate as itself, submit another client's `client_id` in the token request body, and cause grant and scope validation to run under that other client identity. Affected Surface The affected public surface is the OAuth2 token endpoint handling for: - `client_credentials` - `password` / Resource Owner Password Credentials The issue is relevant to OAuthlib provider…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details 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…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A timing side-channel vulnerability exists in the PKCE (RFC 7636) implementation of the Authorization Code Grant flow. The codechallengemethodplain function uses Python's standard == operator for string comparison instead of a constant-time comparison function, potentially allowing timing-based attacks. Affected Component - File: oauthlib/oauth2/rfc6749/granttypes/authorizationcode.py - Functions: codechallengemethodplain, codechallengemethods256 - Vulnerability Type: CWE-208 (Observable Timing Discrepancy) Technical Details Python's == operator uses short-circuit evaluation when comparing strings: 1. Returns False immediately if lengths differ 2. Compares characters left-to-right, stopping at first mismatch This means comparison time varies linearly with the length of the common prefix between the attacker-supplied verifier and the stored challenge, creating a measurable timing oracle. Proof of Concept Tested locally against oauthlib source (network jitter eliminated to…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When enablejsonp=True, oauthlib's RevocationEndpoint reflects the user-supplied callback parameter directly into JavaScript response bodies on both success and error paths without validating that it is a legal JSONP callback name. This allows arbitrary JavaScript response generation instead of a restricted function call, making the documented JSONP revocation feature unsafe for browser-based JSONP consumption when attackers can influence callback. Details The issue is in oauthlib/oauth2/rfc6749/endpoints/revocation.py. When enablejsonp=True is passed to the RevocationEndpoint constructor, two code paths wrap the response body using the user-supplied request.callback parameter: The request.callback value comes from HTTP request parameters, either the query string or POST body, via the Request class in oauthlib/common.py (lines 394-395), which merges query and body parameters into params. Any value the client sends as callback is used verbatim. There is no validation of any…
Recommended action: Upgrade to 4.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact - Attacker providing malicious redirect uri can cause DoS to oauthlib's web application. - Attacker can also leverage usage of urivalidate functions depending where it is used. What kind of vulnerability is it? Who is impacted? Oauthlib applications using OAuth2.0 provider support or use directly urivalidate function. Patches Has the problem been patched? What versions should users upgrade to? Issue fixed in 3.2.2 release. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? The redirecturi can be verified in web toolkit (i.e bottle-oauthlib, django-oauth-toolkit, ...) before oauthlib is called. A sample check if : is present to reject the request can prevent the DoS, assuming no port or IPv6 is fundamentally required. References Attack Vector: - Attacker providing malicious redirect uri: https://github.com/oauthlib/oauthlib/blob/d4bafd9f1d0eba3766e933b1ac598cbbf37b8914/oauthlib/oauth2/rfc6749/granttypes/base.py#L232 - Vulnerable…
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.