CVE-2026-49264: 
Python vulnerability analysis and mitigation

CVE-2026-49264 is a JSONP callback injection vulnerability in oauthlib's RevocationEndpoint that allows arbitrary JavaScript response generation when enable_jsonp=True is configured. The vulnerability affects oauthlib versions >= 0.6.1 through 3.3.1 (pip package) and has been present since the revocation endpoint was introduced in 2013. It was reported by researcher Nadav0077, published as GHSA-hj66-6f7g-4r5v on September 28, 2026, and patched in oauthlib 4.0.0. The CVSS v3.1 base score is 6.1 (Medium) (GitHub Advisory, oauthlib Advisory).

The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation / Cross-site Scripting), specifically a JSONP callback injection. In oauthlib/oauth2/rfc6749/endpoints/revocation.py, when enable_jsonp=True is set on the RevocationEndpoint constructor, the request.callback value — sourced verbatim from HTTP query string or POST body parameters — is interpolated directly into the JavaScript response body on both the error path ('{}({});'.format(request.callback, response_body)) and the success path (request.callback + '();'). There is no validation that the callback value is a legal JavaScript identifier, no character whitelist, and no escaping or sanitization. An attacker can supply a payload such as alert(document.cookie)// as the callback parameter, causing the server to return syntactically valid JavaScript that executes the attacker's code before commenting out the remainder of the line (GitHub Advisory, oauthlib Advisory).

Any oauthlib-based authorization server that explicitly enables JSONP on the revocation endpoint (enable_jsonp=True) returns attacker-controlled JavaScript in its HTTP response body. If a legitimate OAuth client application loads this endpoint's response as JSONP via a <script src> tag and an attacker can influence the callback parameter, the attacker's code executes in the client application's browser origin — granting access to the page's DOM, cookies, session tokens, and any data accessible to scripts in that origin. The authorization server effectively becomes a delivery mechanism for attacker-controlled JavaScript trusted by client applications. Availability is not impacted, but both confidentiality and integrity of the client application's browser context are at risk (GitHub Advisory).

A working proof-of-concept is publicly documented in the GitHub Security Advisory itself, demonstrating payload reflection on both the error and success response paths with no authentication required. The vulnerability requires user interaction (a victim's browser must load the crafted JSONP endpoint) and is only exploitable when enable_jsonp=True is explicitly configured — a non-default setting. No in-the-wild exploitation has been reported, no CISA KEV listing exists, and no threat actor attribution is available. The EPSS score is not yet published for this CVE (GitHub Advisory, oauthlib Advisory).

1. Identify a vulnerable deployment: Locate an oauthlib-based OAuth 2.0 authorization server running oauthlib >= 0.6.1 and <= 3.3.1 with RevocationEndpoint instantiated using enable_jsonp=True. This can be inferred by sending a test request with a benign callback parameter and observing whether the response wraps the body in a JSONP call.
2. Craft a malicious callback payload: Construct a callback value containing arbitrary JavaScript followed by // to comment out the remainder of the response line, e.g., alert(document.cookie)// or window.location='https://evil.com/'//.
3. Send the crafted revocation request: Submit a POST request to the revocation endpoint with the malicious callback:

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"}); 4. Deliver the payload to a victim: Host a page on a controlled domain that includes a <script src="https://auth.example.com/revoke?token=x&callback=alert(document.cookie)//"> tag, or inject the crafted URL into a legitimate OAuth client application that uses JSONP revocation. 5. Achieve code execution in victim's origin: When the victim's browser loads the script tag, the attacker's JavaScript executes in the origin of the including page, enabling cookie theft, DOM manipulation, credential harvesting, or redirection (GitHub Advisory, oauthlib Advisory).

• Network: HTTP POST or GET requests to the token revocation endpoint (/revoke or equivalent) containing a callback parameter with characters outside the safe identifier pattern (e.g., parentheses (), slashes //, quotes, or spaces); outbound requests from victim browsers to attacker-controlled domains following JSONP endpoint access.
• Logs: Web server or application logs showing revocation endpoint requests with callback values containing JavaScript syntax characters such as (, ), //, ', or =; repeated requests with varying callback payloads suggesting probing activity.
• Response Content: Revocation endpoint responses with Content-Type: application/json but body content that does not begin with a valid JavaScript identifier pattern (i.e., body starts with characters like (, digits, or special symbols before the function call syntax).

The primary remediation is to upgrade oauthlib to version 4.0.0, which removes JSONP support entirely from the RevocationEndpoint — the enable_jsonp parameter has been removed from the constructor and the callback parameter removed from prepare_token_revocation_request (oauthlib PR #951, Patch Commit). For deployments that cannot immediately upgrade, the interim workaround is to avoid setting enable_jsonp=True on RevocationEndpoint and migrate cross-origin revocation flows to CORS-based mechanisms, which are supported by all modern browsers. If JSONP must remain enabled temporarily, add server-side validation of the callback parameter against the pattern ^[a-zA-Z_$][a-zA-Z0-9_$]*(\.[a-zA-Z_$][a-zA-Z0-9_$]*)*$ and reject or nullify non-conforming values before use (GitHub Advisory).

The fix was implemented by oauthlib maintainer JonathanHuot, who chose to fully remove JSONP support rather than patch the callback validation, citing that CORS has superseded JSONP for cross-origin requests and that JSONP introduces inherent security risks (oauthlib PR #951). The advisory notes that downstream projects such as databricks-sql-python have already moved to allow oauthlib 4.x to address this CVE. The vulnerability was reported by researcher Nadav0077 and has been tracked by Tenable cloud security plugins and the GitLab advisory database (GitHub Advisory).