CVE-2026-40864: Jupyter CSRF bypass on spawn and

CISO Take

JupyterHub versions 4.1.0 through 5.4.4 contain an XSRF bypass where the server incorrectly accepts requests carrying 'Sec-Fetch-Mode: no-cors' as same-origin, allowing cross-origin form POSTs to reach sensitive endpoints — including /hub/spawn and /hub/accept-share — without a valid CSRF token. While an attacker cannot access any spawned server, the share-acceptance vector is the more dangerous path: in collaborative multi-tenant AI/ML environments, a visiting authenticated user can be silently forced to accept access to an attacker-controlled notebook server, a subtle lateral movement foothold into shared data science infrastructure. JupyterHub has 1,862 downstream dependents and an OpenSSF score of 4.8/10; no public exploit exists and it is absent from CISA KEV, placing urgency at moderate — but any enterprise running shared JupyterHub for ML workflows should treat the share-acceptance bypass as a priority given its low exploitation bar. Upgrade to JupyterHub 5.4.5 immediately, or if a reverse proxy is in place, block requests with 'Sec-Fetch-Mode: no-cors' as an interim control.

Sources: NVD GitHub Advisory ATLAS OpenSSF

What is the risk?

Medium risk. CVSS 5.4 correctly reflects the constrained impact: no confidentiality loss and only limited integrity and availability degradation. Exploitability is high — the attacker needs no privileges and the attack is browser-native requiring only that a victim visit a malicious page while authenticated (UI:R). The spawn vector is primarily a resource exhaustion concern in cloud-billed environments; the share-acceptance vector is the higher-severity path, enabling silent lateral movement into AI development workspaces. No KEV entry, no EPSS data, and no public exploit templates reduce immediate mass-exploitation risk, but the 1,862 downstream dependents broaden organizational exposure considerably.

How does the attack unfold?

Social Engineering

Attacker sends authenticated JupyterHub user a phishing link to an attacker-controlled webpage, relying on standard social engineering to achieve the required user interaction.

AML.T0011.003

CSRF Exploitation

Victim's browser sends a cross-origin form POST to /hub/accept-share; JupyterHub 4.1.0–5.4.4 incorrectly trusts Sec-Fetch-Mode: no-cors as a same-origin request, bypassing XSRF token validation entirely.

AML.T0049

Unauthorized Share Acceptance

The share acceptance is processed under the victim's authenticated session, granting them access to the attacker's pre-configured malicious notebook server without the victim's awareness or consent.

AML.T0012

AI Environment Compromise

Victim opens the shared server and executes attacker-controlled notebooks, enabling data exfiltration, credential theft, or injection of malicious code into the victim's AI development pipelines.

AML.T0048.003

Social Engineering

Attacker sends authenticated JupyterHub user a phishing link to an attacker-controlled webpage, relying on standard social engineering to achieve the required user interaction.

AML.T0011.003

CSRF Exploitation

Victim's browser sends a cross-origin form POST to /hub/accept-share; JupyterHub 4.1.0–5.4.4 incorrectly trusts Sec-Fetch-Mode: no-cors as a same-origin request, bypassing XSRF token validation entirely.

AML.T0049

Unauthorized Share Acceptance

The share acceptance is processed under the victim's authenticated session, granting them access to the attacker's pre-configured malicious notebook server without the victim's awareness or consent.

AML.T0012

AI Environment Compromise

Victim opens the shared server and executes attacker-controlled notebooks, enabling data exfiltration, credential theft, or injection of malicious code into the victim's AI development pipelines.

AML.T0048.003

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	>= 4.1.0, < 5.4.5	`5.4.5`
13.2K OpenSSF 5.8 1.9K dependents Pushed 5d ago 79% patched ~9d to patch Full package profile →

Do you use Jupyter? You're affected.

How severe is it?

CVSS 3.1

5.4 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 5% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Unchanged

C None

I Low

A Low

What should I do?

5 steps

Upgrade jupyterhub to version 5.4.5 immediately (pip install 'jupyterhub>=5.4.5').
If a reverse proxy (nginx, Caddy, HAProxy) fronts JupyterHub, add a header filter to reject or drop any inbound request where 'Sec-Fetch-Mode: no-cors' is present — this is an effective interim workaround without requiring an upgrade.
Audit JupyterHub access logs for anomalous patterns: repeated /hub/spawn calls from unexpected referrers, or /hub/accept-share calls without corresponding UI navigation.
Review and revoke any unrecognized server share grants in the admin panel.
Restrict JupyterHub access to VPN or internal network to reduce the attack surface for socially engineering authenticated users into visiting malicious pages.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass DoS Framework AML.T0011.003 - Malicious Link AML.T0034 - Cost Harvesting AML.T0048.003 - User Harm AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.9.3 - AI system operation

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain AI system performance and security

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-40864?

JupyterHub versions 4.1.0 through 5.4.4 contain an XSRF bypass where the server incorrectly accepts requests carrying 'Sec-Fetch-Mode: no-cors' as same-origin, allowing cross-origin form POSTs to reach sensitive endpoints — including /hub/spawn and /hub/accept-share — without a valid CSRF token. While an attacker cannot access any spawned server, the share-acceptance vector is the more dangerous path: in collaborative multi-tenant AI/ML environments, a visiting authenticated user can be silently forced to accept access to an attacker-controlled notebook server, a subtle lateral movement foothold into shared data science infrastructure. JupyterHub has 1,862 downstream dependents and an OpenSSF score of 4.8/10; no public exploit exists and it is absent from CISA KEV, placing urgency at moderate — but any enterprise running shared JupyterHub for ML workflows should treat the share-acceptance bypass as a priority given its low exploitation bar. Upgrade to JupyterHub 5.4.5 immediately, or if a reverse proxy is in place, block requests with 'Sec-Fetch-Mode: no-cors' as an interim control.

Is CVE-2026-40864 actively exploited?

No confirmed active exploitation of CVE-2026-40864 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-40864?

1. Upgrade jupyterhub to version 5.4.5 immediately (pip install 'jupyterhub>=5.4.5'). 2. If a reverse proxy (nginx, Caddy, HAProxy) fronts JupyterHub, add a header filter to reject or drop any inbound request where 'Sec-Fetch-Mode: no-cors' is present — this is an effective interim workaround without requiring an upgrade. 3. Audit JupyterHub access logs for anomalous patterns: repeated /hub/spawn calls from unexpected referrers, or /hub/accept-share calls without corresponding UI navigation. 4. Review and revoke any unrecognized server share grants in the admin panel. 5. Restrict JupyterHub access to VPN or internal network to reduce the attack surface for socially engineering authenticated users into visiting malicious pages.

What systems are affected by CVE-2026-40864?

This vulnerability affects the following AI/ML architecture patterns: AI/ML development platforms, Multi-tenant Jupyter environments, Training pipelines, Shared data science workspaces.

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

CVE-2026-40864 has a CVSS v3.1 base score of 5.4 (MEDIUM). The EPSS exploitation probability is 0.16%.

What is the AI security impact?

Affected AI Architectures

AI/ML development platformsMulti-tenant Jupyter environmentsTraining pipelinesShared data science workspaces

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link

AML.T0034 Cost Harvesting

AML.T0048.003 User Harm

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.9.3

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

## Summary JupyterHub's XSRF protection (updated in 4.1.0) inappropriately treated requests with `Sec-Fetch-Mode: no-cors` as same-origin requests, which they are not, bypassing XSRF checks. The JSON API is not affected, only HTTP form endpoints, such as `/hub/spawn` and `/hub/accept-share`, meaning attackers could trigger server spawn (but not access the server) and if the attacker is a JupyterHub user permitted to share access to their server, cause a user to accept a share and have access to the attacker's server. ## Patches Upgrade to JupyterHub 5.4.5. ## Mitigations If a reverse proxy is in use, drop requests to JupyterHub with `Sec-Fetch-Mode: no-cors`.

Exploitation Scenario

An attacker holding a valid JupyterHub account on the target platform prepares a notebook server pre-loaded with a data exfiltration or credential harvesting script. They generate a share token for their server via the legitimate UI, then craft a webpage that embeds a hidden HTML form POSTing to the victim organization's /hub/accept-share endpoint — the browser naturally sends 'Sec-Fetch-Mode: no-cors' on cross-origin form submissions, which vulnerable JupyterHub versions incorrectly treat as trusted. The attacker phishes an authenticated JupyterHub user with this link. Upon visiting, the victim's browser silently submits the POST under their authenticated session; JupyterHub skips CSRF validation and processes the share acceptance. The victim now has access to the attacker's server, and the next time they open JupyterHub they may launch and execute the malicious notebooks, enabling code execution in the AI development environment.

Weaknesses (CWE)

CWE-352 Cross-Site Request Forgery (CSRF) Primary

CWE-352 — Cross-Site Request Forgery (CSRF): The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
[Implementation] Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Source: MITRE CWE corpus.