CVE-2026-86049: 
Python vulnerability analysis and mitigation

CVE-2026-86049 is an information disclosure vulnerability in Jupyter Server where the 5xx request logging path in jupyter_server/log.py copies the Referer HTTP header into a JSON log block without applying the token-scrubbing logic used for the request URI. This allows authentication tokens embedded in Referer URLs to be written to server logs in plaintext during normal token-based login and launch flows. All versions of jupyter_server up to and including 2.20.0 are affected; the issue is fixed in version 2.21.0. It carries a CVSS v3.1 base score of 7.1 (High) (Github Advisory, Security Advisory). The vulnerability was reported by DavidCarliez, published privately on August 28, 2026, and disclosed publicly on September 17, 2026.

The root cause is classified as CWE-532 (Insertion of Sensitive Information into Log File). In jupyter_server/log.py, the log_request() function constructs a JSON block of selected request headers (Host, Accept, Referer, User-Agent) for logging when a 5xx response occurs. While the request URI undergoes token scrubbing via _scrub_uri(), the Referer header value was copied as-is without the same sanitization, allowing any token present in the Referer URL to appear in plaintext in the log output. The fix (commit 5251352, PR #1681) applies _scrub_uri() to the Referer header value before it is added to the logged JSON block (Security Advisory, Fix Commit). A public proof-of-concept is included in the advisory, demonstrating that any malformed POST request triggering a 500 error while carrying a token-bearing Referer header is sufficient to reproduce the leak.

An attacker with read access to Jupyter Server logs can extract plaintext authentication tokens from 500-error log entries, then use those tokens to authenticate as the affected user and gain full access to their Jupyter Server instance. This enables unauthorized execution of arbitrary code via notebooks, access to sensitive data, and potential lateral movement within environments where Jupyter Server has broad filesystem or network access. The confidentiality, integrity, and availability impacts are all rated High, reflecting the full scope of permissions a valid Jupyter token grants (Github Advisory).

A public proof-of-concept is included in the official security advisory, demonstrating exploitation with a simple curl command. Exploitation requires low privileges (an existing low-privileged account or network position to trigger a 500 error) and user interaction (a legitimate user must make a request with a token-bearing Referer header). There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the EPSS score is 0.0. The vulnerability is not listed in the CISA KEV catalog (Github Advisory, Feedly).

1. Gain log read access: Obtain access to the Jupyter Server log files, either through a compromised system account, shared log aggregation infrastructure, or a misconfigured log management system that exposes logs to low-privileged users.
2. Trigger a 500 error with a token-bearing Referer: Send a malformed HTTP request to the target Jupyter Server that will result in an HTTP 500 response, while setting the Referer header to a URL containing a valid or previously observed token. Example:

curl -i -X POST \
  -H 'Content-Type: application/json' \
  -H 'Referer: http://127.0.0.1:8899/tree?token=REFERTOKEN' \
  --data '{"name":123}' \
  'http://127.0.0.1:8899/api/kernels?token=VALIDTOKEN'

3. Extract the token from logs: Read the server log and locate the JSON header block logged for the 500 response. The Referer field will contain the token in plaintext (e.g., "Referer": "http://127.0.0.1:8899/tree?token=REFERTOKEN").
4. Authenticate as the victim: Use the recovered token to authenticate to the Jupyter Server (e.g., by appending ?token=REFERTOKEN to any Jupyter URL), gaining full access to the victim's notebooks, files, and kernel execution environment (Security Advisory).

• Logs: Server logs containing JSON header blocks with unredacted Referer values including ?token= parameters in 500-error entries (e.g., "Referer": "http://<host>/tree?token=<plaintext_token>"); presence of [E ... ServerApp] 500 POST entries where the referer field is not scrubbed to [secret].
• Network: Repeated malformed POST requests to Jupyter API endpoints (e.g., /api/kernels) from unexpected source IPs, particularly with unusual or invalid JSON bodies designed to trigger 500 errors.
• Logs: Subsequent authentication events using tokens that were previously only seen in Referer headers, potentially from different IP addresses than the original session, indicating token theft and reuse (Security Advisory).

Upgrade jupyter_server to version 2.21.0 or later, which applies _scrub_uri() to the Referer header before logging, preventing token exposure (Release v2.21.0). As interim workarounds, restrict read access to Jupyter Server log files to only trusted administrators, and configure Jupyter to use password-based or other authentication flows that do not embed tokens in URLs. Rotating any tokens that may have been exposed in logs prior to patching is also recommended (Github Advisory).