CVE-2026-49264

Summary

When enable_jsonp=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 enable_jsonp=True is passed to the RevocationEndpoint constructor, two code paths wrap the response body using the user-supplied request.callback parameter:

# Error response path (line 72-73):
if self.enable_jsonp and request.callback:
    response_body = '{}({});'.format(request.callback, response_body)

# Success response path (line 81-82):
if self.enable_jsonp and request.callback:
    response_body = request.callback + '();'

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 kind on the callback parameter:

• No check that it is a valid JavaScript identifier
• No whitelist of allowed characters
• No escaping or sanitization

A safe JSONP implementation must validate that the callback is a legal JavaScript function name (e.g., matching ^[a-zA-Z_$][a-zA-Z0-9_$.]*$). Without this, the attacker controls the JavaScript code returned in the response body. This is the standard mitigation used by jQuery, Express.js, Google APIs, and other major JSONP implementations.

How the injection works:

An attacker sends a revocation request with a crafted callback value:

POST /revoke HTTP/1.1
Content-Type: application/x-www-form-urlencoded

token=anything&callback=alert(document.cookie)//

The server responds with:

alert(document.cookie)//({"error": "invalid_client"});

This is syntactically valid JavaScript. alert(document.cookie) executes as a statement, and // comments out the rest of the line. The attacker has full control over the code that appears before the //.

Execution context and attack surface:

JSONP works by having a browser load a remote script via <script src="...">. The loaded script executes in the origin of the including page, not the remote server. This means a <script src="https://auth.example.com/revoke?token=x&callback=payload"> tag on evil.com would execute the payload in evil.com's context, not the auth server's context.

The impact comes from client-side integrations that consume this endpoint as trusted JSONP. If a legitimate OAuth client includes <script src> pointed at the revocation endpoint and an attacker can influence the callback value (e.g., via query parameter injection, a reflected value, or a man-in-the-middle downgrade), the attacker controls what code runs in the client application's origin. The authorization server becomes a source of attacker-controlled JavaScript that client applications trust and execute.

Note: the enable_jsonp parameter defaults to False, so only deployments that explicitly opt in are affected. However, this is a supported, documented library feature, not a debug flag. The client-side library includes prepare_token_revocation_request() with an explicit callback parameter (oauthlib/oauth2/rfc6749/parameters.py, line 174), and the documentation shows JSONP revocation as a use case (oauthlib/oauth2/rfc6749/clients/base.py, lines 351-358). The existing test suite tests JSONP callback reflection with a benign value (test_revocation_endpoint.py, lines 91-101) but does not test for injection. Deployments that enable JSONP typically do so to support older browsers or cross-origin revocation from…

AuthLib is a framework which implements the logic of OAuth1 or OAuth2 without assuming a specific HTTP request object or web framework. Use it to graft OAuth client support onto your favorite HTTP library, or provide support onto your favourite web framework. If you're a maintainer of such a library, write a thin veneer on top of OAuthLib and get OAuth support for very little effort.

Security Fix(es):

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 0.6.1 until 4.0.0, OAuthLib's RevocationEndpoint in oauthlib/oauth2/rfc6749/endpoints/revocation.py reflects an unvalidated callback request parameter into success and error response bodies when enable_jsonp=True. The callback can come from the query string or request body and is used without restricting it to a legal JavaScript function name. A browser application that loads the revocation response as trusted JSONP and permits attacker influence over callback can therefore execute attacker-controlled JavaScript in the including application's origin, with access to its DOM and script-accessible data. The feature is disabled by default, so only deployments that explicitly enable JSONP are affected. This issue is fixed in version 4.0.0.(CVE-2026-49264)

AuthLib is a framework which implements the logic of OAuth1 or OAuth2 without assuming a specific HTTP request object or web framework. Use it to graft OAuth client support onto your favorite HTTP library, or provide support onto your favourite web framework. If you're a maintainer of such a library, write a thin veneer on top of OAuthLib and get OAuth support for very little effort.

Security Fix(es):

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 0.6.1 until 4.0.0, OAuthLib's RevocationEndpoint in oauthlib/oauth2/rfc6749/endpoints/revocation.py reflects an unvalidated callback request parameter into success and error response bodies when enable_jsonp=True. The callback can come from the query string or request body and is used without restricting it to a legal JavaScript function name. A browser application that loads the revocation response as trusted JSONP and permits attacker influence over callback can therefore execute attacker-controlled JavaScript in the including application's origin, with access to its DOM and script-accessible data. The feature is disabled by default, so only deployments that explicitly enable JSONP are affected. This issue is fixed in version 4.0.0.(CVE-2026-49264)

AuthLib is a framework which implements the logic of OAuth1 or OAuth2 without assuming a specific HTTP request object or web framework. Use it to graft OAuth client support onto your favorite HTTP library, or provide support onto your favourite web framework. If you're a maintainer of such a library, write a thin veneer on top of OAuthLib and get OAuth support for very little effort.

Security Fix(es):

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 0.6.1 until 4.0.0, OAuthLib's RevocationEndpoint in oauthlib/oauth2/rfc6749/endpoints/revocation.py reflects an unvalidated callback request parameter into success and error response bodies when enable_jsonp=True. The callback can come from the query string or request body and is used without restricting it to a legal JavaScript function name. A browser application that loads the revocation response as trusted JSONP and permits attacker influence over callback can therefore execute attacker-controlled JavaScript in the including application's origin, with access to its DOM and script-accessible data. The feature is disabled by default, so only deployments that explicitly enable JSONP are affected. This issue is fixed in version 4.0.0.(CVE-2026-49264)

AuthLib is a framework which implements the logic of OAuth1 or OAuth2 without assuming a specific HTTP request object or web framework. Use it to graft OAuth client support onto your favorite HTTP library, or provide support onto your favourite web framework. If you're a maintainer of such a library, write a thin veneer on top of OAuthLib and get OAuth support for very little effort.

Security Fix(es):

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 0.6.1 until 4.0.0, OAuthLib's RevocationEndpoint in oauthlib/oauth2/rfc6749/endpoints/revocation.py reflects an unvalidated callback request parameter into success and error response bodies when enable_jsonp=True. The callback can come from the query string or request body and is used without restricting it to a legal JavaScript function name. A browser application that loads the revocation response as trusted JSONP and permits attacker influence over callback can therefore execute attacker-controlled JavaScript in the including application's origin, with access to its DOM and script-accessible data. The feature is disabled by default, so only deployments that explicitly enable JSONP are affected. This issue is fixed in version 4.0.0.(CVE-2026-49264)

Summary

When enable_jsonp=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 enable_jsonp=True is passed to the RevocationEndpoint constructor, two code paths wrap the response body using the user-supplied request.callback parameter:

# Error response path (line 72-73):
if self.enable_jsonp and request.callback:
    response_body = '{}({});'.format(request.callback, response_body)

# Success response path (line 81-82):
if self.enable_jsonp and request.callback:
    response_body = request.callback + '();'

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 kind on the callback parameter:

• No check that it is a valid JavaScript identifier
• No whitelist of allowed characters
• No escaping or sanitization

A safe JSONP implementation must validate that the callback is a legal JavaScript function name (e.g., matching ^[a-zA-Z_$][a-zA-Z0-9_$.]*$). Without this, the attacker controls the JavaScript code returned in the response body. This is the standard mitigation used by jQuery, Express.js, Google APIs, and other major JSONP implementations.

How the injection works:

An attacker sends a revocation request with a crafted callback value:

POST /revoke HTTP/1.1
Content-Type: application/x-www-form-urlencoded

token=anything&callback=alert(document.cookie)//

The server responds with:

alert(document.cookie)//({"error": "invalid_client"});

This is syntactically valid JavaScript. alert(document.cookie) executes as a statement, and // comments out the rest of the line. The attacker has full control over the code that appears before the //.

Execution context and attack surface:

JSONP works by having a browser load a remote script via <script src="...">. The loaded script executes in the origin of the including page, not the remote server. This means a <script src="https://auth.example.com/revoke?token=x&callback=payload"> tag on evil.com would execute the payload in evil.com's context, not the auth server's context.

The impact comes from client-side integrations that consume this endpoint as trusted JSONP. If a legitimate OAuth client includes <script src> pointed at the revocation endpoint and an attacker can influence the callback value (e.g., via query parameter injection, a reflected value, or a man-in-the-middle downgrade), the attacker controls what code runs in the client application's origin. The authorization server becomes a source of attacker-controlled JavaScript that client applications trust and execute.

Note: the enable_jsonp parameter defaults to False, so only deployments that explicitly opt in are affected. However, this is a supported, documented library feature, not a debug flag. The client-side library includes prepare_token_revocation_request() with an explicit callback parameter (oauthlib/oauth2/rfc6749/parameters.py, line 174), and the documentation shows JSONP revocation as a use case (oauthlib/oauth2/rfc6749/clients/base.py, lines 351-358). The existing test suite tests JSONP callback reflection with a benign value (test_revocation_endpoint.py, lines 91-101) but does not test for injection. Deployments that enable JSONP typically do so to support older browsers or cross-origin revocation from…

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 0.6.1 until 4.0.0, OAuthLib's RevocationEndpoint in oauthlib/oauth2/rfc6749/endpoints/revocation.py reflects an unvalidated callback request parameter into success and error response bodies when enable_jsonp=True. The callback can come from the query string or request body and is used without restricting it to a legal JavaScript function name. A browser application that loads the revocation response as trusted JSONP and permits attacker influence over callback can therefore execute attacker-controlled JavaScript in the including application's origin, with access to its DOM and script-accessible data. The feature is disabled by default, so only deployments that explicitly enable JSONP are affected. This issue is fixed in version 4.0.0.

OAuthLib is an implementation of the OAuth request-signing logic for Python 3.6+. From 0.6.1 until 4.0.0, OAuthLib's RevocationEndpoint in oauthlib/oauth2/rfc6749/endpoints/revocation.py reflects an unvalidated callback request parameter into success and error response bodies when enable_jsonp=True. The callback can come from the query string or request body and is used without restricting it to a legal JavaScript function name. A browser application that loads the revocation response as trusted JSONP and permits attacker influence over callback can therefore execute attacker-controlled JavaScript in the including application's origin, with access to its DOM and script-accessible data. The feature is disabled by default, so only deployments that explicitly enable JSONP are affected. This issue is fixed in version 4.0.0.

These are all security issues fixed in the python313-oauthlib-4.0.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-oauthlib fixes the following issues:

• CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (bsc#1283526).
• CVE-2026-49265: Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (bsc#1283527).

This update for python-oauthlib fixes the following issues:

• CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (bsc#1283526).
• CVE-2026-49265: Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (bsc#1283527).

This update for python-oauthlib fixes the following issues:

• CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (bsc#1283526).
• CVE-2026-49265: Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (bsc#1283527).

This update for python-oauthlib fixes the following issues:

• CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (bsc#1283526).
• CVE-2026-49265: Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (bsc#1283527).

This update for python-oauthlib fixes the following issue:

• CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (bsc#1283526).

This update for python-oauthlib fixes the following issues:

• CVE-2026-49264: Oauthlib : Unsafe JSONP callback injection in RevocationEndpoint allows arbitrary JavaScript response generation (bsc#1283526).
• CVE-2026-49265: Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (bsc#1283527).