When `enable_jsonp=True` is passed to oauthlib's `RevocationEndpoint` (`oauthlib/oauth2/rfc6749/endpoints/revocation.py`), the endpoint reflects the user-supplied `callback` request parameter directly into the JavaScript response body on both the success and error paths, with no validation that it is a legal JSONP callback name:

```python
# Error response path
if self.enable_jsonp and request.callback:
    response_body = '{}({});'.format(request.callback, response_body)

# Success response path
if self.enable_jsonp and request.callback:
    response_body = request.callback + '();'
```

`request.callback` comes straight from the HTTP query string or POST body (merged in `oauthlib/common.py`'s `Request` class) with no sanitization, whitelist, or JS-identifier validation applied.

Exploit example:

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

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

returns:

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

which is syntactically valid JavaScript (`alert(document.cookie)` executes, `//` comments out the trailing object literal). Since JSONP works by loading the response via `<script src="...">`, the attacker-controlled script executes in the origin of the page that embeds the `<script>` tag. A legitimate OAuth client that uses oauthlib's documented JSONP revocation support (`prepare_token_revocation_request()` in `oauthlib/oauth2/rfc6749/parameters.py`) and allows an attacker to influence the `callback` value (reflected value, query injection, MITM downgrade) hands that attacker arbitrary JS execution in the client application's origin.

`enable_jsonp` defaults to `False`, so only deployments that explicitly opt into this documented feature are affected.

Verification: confirmed directly against oauthlib's GitHub source. The vulnerable code is present unchanged in tag `v3.3.1` (`oauthlib/oauth2/rfc6749/endpoints/revocation.py`). Tag `v4.0.0` (the fix release) removes the `enable_jsonp` feature from `RevocationEndpoint` entirely, rather than just validating the callback.

Source: GHSA-hj66-6f7g-4r5v (https://github.com/oauthlib/oauthlib/security/advisories/GHSA-hj66-6f7g-4r5v), published 2026-09-28 by the oauthlib maintainers, CWE-79, reported by GitHub user Nadav0077.