CVE-2026-86049: Jupyter Referer token leak

Q: Is CVE-2026-86049 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-86049, increasing the risk of exploitation.

Q: How to fix CVE-2026-86049?

1) Upgrade jupyter_server to 2.21.0 or later (fix: PR #1681, commit 52513529). 2) Invalidate and rotate Jupyter tokens and passwords for instances running vulnerable versions, especially if logs were shipped to shared systems. 3) Search existing logs and SIEM indices for 5xx entries whose Referer contains 'token=' and purge or redact them. 4) Restrict read access to Jupyter logs and log aggregation, and apply log redaction rules for 'token=' query parameters at the collector. 5) Do not expose Jupyter directly to the internet; put it behind an authenticating proxy or VPN and prefer short-lived tokens or SSO. 6) Monitor for unusual kernel launches, new sessions from unexpected IPs, and use of tokens that appeared in logs.

Q: What systems are affected by CVE-2026-86049?

This vulnerability affects the following AI/ML architecture patterns: Notebook-based ML development environments, Training pipelines, Shared data science platforms, Model experimentation workspaces, Centralized logging for AI infrastructure.

Q: What is the CVSS score for CVE-2026-86049?

CVE-2026-86049 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.42%.

CISO Take

Jupyter Server before 2.21.0 writes the raw Referer header to its logs when a request returns HTTP 500, bypassing the token scrubbing applied to the request URI, so any session token embedded in that Referer is stored in plaintext. The attack is hard to pull off (high complexity, user interaction required, low privileges, and a log-read prerequisite), and EPSS sits at 0.4% (66th percentile) with no KEV listing and a CISA SSVC decision of TRACK. Even so, a public PoC exists and the package has 1,892 downstream dependents and 41 other CVEs on record, while a stolen token gives full Jupyter permissions, which in practice means code execution in notebooks with access to data, models and cloud credentials. Upgrade jupyter_server to 2.21.0 or later, rotate any tokens that may have appeared in logs, and restrict and audit access to Jupyter log files and the log aggregation pipeline.

Sources:NVDGitHub AdvisoryEPSSOpenSSFATLAS

What is the risk?

Medium-to-high rather than critical. CVSS 7.1 reflects high confidentiality, integrity and availability impact if a token is recovered, but exploitation needs a 500 error triggered with a token-bearing Referer, a user action, and read access to the logs. EPSS is low (0.00416), the CVE is not in KEV, and SSVC says TRACK. Exposure is highest in shared, multi-user or centrally logged Jupyter deployments (JupyterHub-style, cloud notebooks, Kubernetes with log forwarding to SIEM or shared storage), where many people can read logs. Single-user localhost instances carry little risk.

How does the attack unfold?

Token exposure

A request carrying a token-bearing Referer triggers an HTTP 500 and the server logs the unscrubbed Referer header in plaintext.

AML.T0055

Credential harvesting

The attacker reads the Jupyter logs through shared access or a log pipeline and extracts the token from the Referer field.

AML.T0055

Account takeover

The attacker replays the stolen token to authenticate to the victim's Jupyter Server with the victim's permissions.

AML.T0091.000

Impact

The attacker runs code in kernels, exfiltrates datasets, models and cloud or API credentials, and tampers with notebooks.

Token exposure

A request carrying a token-bearing Referer triggers an HTTP 500 and the server logs the unscrubbed Referer header in plaintext.

AML.T0055

Credential harvesting

The attacker reads the Jupyter logs through shared access or a log pipeline and extracts the token from the Referer field.

AML.T0055

Account takeover

The attacker replays the stolen token to authenticate to the victim's Jupyter Server with the victim's permissions.

AML.T0091.000

Impact

The attacker runs code in kernels, exfiltrates datasets, models and cloud or API credentials, and tampers with notebooks.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	—	No patch
13.5KOpenSSF 5.81.9K dependentsPushed 6d ago56% patched~28d to patchFull package profile →
Jupyter	pip	<= 2.20.0	`2.21.0`
13.5KOpenSSF 5.81.9K dependentsPushed 6d ago56% patched~28d to patchFull package profile →

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACHigh

PRLow

UIRequired

SUnchanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Upgrade jupyter_server to 2.21.0 or later (fix: PR #1681, commit 52513529). 2) Invalidate and rotate Jupyter tokens and passwords for instances running vulnerable versions, especially if logs were shipped to shared systems. 3) Search existing logs and SIEM indices for 5xx entries whose Referer contains 'token=' and purge or redact them. 4) Restrict read access to Jupyter logs and log aggregation, and apply log redaction rules for 'token=' query parameters at the collector. 5) Do not expose Jupyter directly to the internet; put it behind an authenticating proxy or VPN and prefer short-lived tokens or SSO. 6) Monitor for unusual kernel launches, new sessions from unexpected IPs, and use of tokens that appeared in logs.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data LeakageAuth BypassFrameworkAML.T0012- Valid Accounts AML.T0055- Unsecured Credentials AML.T0091.000- Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.7.4-Quality of data for AI systems / data security

NIST AI RMF

MANAGE 2.3-Responses to previously unknown risks and mechanisms to supersede deployed systems

OWASP LLM Top 10

LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-86049?

Jupyter Server before 2.21.0 writes the raw Referer header to its logs when a request returns HTTP 500, bypassing the token scrubbing applied to the request URI, so any session token embedded in that Referer is stored in plaintext. The attack is hard to pull off (high complexity, user interaction required, low privileges, and a log-read prerequisite), and EPSS sits at 0.4% (66th percentile) with no KEV listing and a CISA SSVC decision of TRACK. Even so, a public PoC exists and the package has 1,892 downstream dependents and 41 other CVEs on record, while a stolen token gives full Jupyter permissions, which in practice means code execution in notebooks with access to data, models and cloud credentials. Upgrade jupyter_server to 2.21.0 or later, rotate any tokens that may have appeared in logs, and restrict and audit access to Jupyter log files and the log aggregation pipeline.

Is CVE-2026-86049 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-86049, increasing the risk of exploitation.

How to fix CVE-2026-86049?

1) Upgrade jupyter_server to 2.21.0 or later (fix: PR #1681, commit 52513529). 2) Invalidate and rotate Jupyter tokens and passwords for instances running vulnerable versions, especially if logs were shipped to shared systems. 3) Search existing logs and SIEM indices for 5xx entries whose Referer contains 'token=' and purge or redact them. 4) Restrict read access to Jupyter logs and log aggregation, and apply log redaction rules for 'token=' query parameters at the collector. 5) Do not expose Jupyter directly to the internet; put it behind an authenticating proxy or VPN and prefer short-lived tokens or SSO. 6) Monitor for unusual kernel launches, new sessions from unexpected IPs, and use of tokens that appeared in logs.

What systems are affected by CVE-2026-86049?

This vulnerability affects the following AI/ML architecture patterns: Notebook-based ML development environments, Training pipelines, Shared data science platforms, Model experimentation workspaces, Centralized logging for AI infrastructure.

What is the CVSS score for CVE-2026-86049?

CVE-2026-86049 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.42%.

What is the AI security impact?

Affected AI Architectures

Notebook-based ML development environmentsTraining pipelinesShared data science platformsModel experimentation workspacesCentralized logging for AI infrastructure

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0055Unsecured Credentials

AML.T0091.000Application Access Token

Compliance Controls Affected

ISO 42001: A.7.4

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

Jupyter Server is the backend for Jupyter web applications. Prior to version 2.21.0, the 5xx request logging path in jupyter_server/log.py copies the Referer header into a JSON header block without applying the token scrubbing used for the request URI. A request that returns HTTP 500 while the Referer contains a token-bearing URL can therefore write that token to server logs in plaintext. An attacker who can read those logs can recover the token and use the affected user's Jupyter Server permissions. This issue is fixed in version 2.21.0.

Exploitation Scenario

An attacker with low-privilege access to a shared data science platform (or to a log aggregation system holding Jupyter logs) waits for, or induces, a request that makes the server return HTTP 500 while the victim's browser sends a Referer containing a URL with the Jupyter token, for example via a crafted link or page that leads the victim into an error path. The unscrubbed Referer is written to the server log. The attacker reads the log, extracts the token, and authenticates to the victim's Jupyter Server. They then open a terminal or notebook kernel, steal cloud and LLM API credentials, exfiltrate datasets and model files, or tamper with notebooks and pipelines.

Weaknesses (CWE)

CWE-532Insertion of Sensitive Information into Log FilePrimary CWE-532Insertion of Sensitive Information into Log FilePrimary CWE-532Insertion of Sensitive Information into Log File

CWE-532 — Insertion of Sensitive Information into Log File: The product writes sensitive information to a log file.

[Architecture and Design, Implementation] Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files.
[Distribution] Remove debug log files before deploying the application into production.

Source: MITRE CWE corpus.