CVE-2026-40934: Jupyter auth cookie survives

Q: Is CVE-2026-40934 actively exploited?

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

Q: How to fix CVE-2026-40934?

1. Patch: Upgrade jupyter-server to 2.18.0+ which regenerates the cookie secret on password change. 2. Immediate workaround: `rm ~/.local/share/jupyter/runtime/jupyter_cookie_secret` followed by server restart to immediately invalidate all active sessions. 3. Detection: Review server access logs for sessions persisting across known password reset timestamps; any authenticated request using a cookie issued before a password change event is suspicious. 4. Architecture hardening: Place Jupyter behind JupyterHub or a reverse proxy with independent session management; restrict Jupyter access to localhost or VPN to reduce cookie interception surface. 5. For containerized environments: restart Jupyter containers after any suspected credential compromise to force secret regeneration.

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

This vulnerability affects the following AI/ML architecture patterns: Jupyter notebook environments, ML development pipelines, Multi-user data science platforms, Training pipelines, Containerized AI development environments.

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

CVE-2026-40934 has a CVSS v3.1 base score of 6.8 (MEDIUM). The EPSS exploitation probability is 0.31%.

CISO Take

Jupyter Server versions up to 2.17.0 permanently store the cookie signing secret on disk and never rotate it, meaning authentication cookies captured before a password change remain cryptographically valid afterward — credential rotation does not revoke active sessions. With 1,862 downstream dependents, this flaw is embedded across a large footprint of data science and AI development infrastructure, where Jupyter typically serves as the central control plane for training pipelines, model development, and credential-laden notebooks. Exploitation probability is low (EPSS 0.065%, no public exploit, not in KEV), but the impact of a successful attack is severe: an adversary who captures a session cookie before a password reset can silently re-enter the environment after the team believes the incident was contained. Upgrade to jupyter-server 2.18.0 immediately; if patching is blocked, delete `~/.local/share/jupyter/runtime/jupyter_cookie_secret` and restart the server to force secret regeneration.

Sources: NVD EPSS GitHub Advisory ATLAS OpenSSF

What is the risk?

Medium severity (CVSS 6.8, AV:N/AC:H/PR:L) with elevated contextual risk in enterprise AI/ML environments. The high attack complexity reflects the prerequisite of prior session capture, but once a cookie is obtained, the persistent access mechanism is trivially exploitable. The critical concern is that this vulnerability silently undermines the primary incident response control for credential compromise — teams executing standard playbooks (force password reset) will believe access has been revoked when it has not. Risk is highest in shared JupyterHub environments, cloud-based AI development platforms, and multi-tenant data science infrastructure where session revocation is a critical security guarantee.

How does the attack unfold?

Session Capture

Adversary obtains a valid Jupyter authentication cookie via phishing, network interception, XSS in rendered notebook output, or access to browser storage on a compromised workstation.

AML.T0055

Failed Revocation

Victim or administrator resets the Jupyter Server password attempting incident containment; the non-rotating cookie secret renders this control ineffective without manual secret deletion.

AML.T0012

Persistent Re-entry

Adversary reuses the pre-reset cookie post-password change, gaining full authenticated access to the Jupyter environment that the organization believes was secured.

AML.T0091.000

AI Environment Exploitation

Adversary executes arbitrary code via notebooks, exfiltrates model weights, training data, and embedded API credentials, or injects malicious code into ML training pipelines.

AML.T0025

Session Capture

Adversary obtains a valid Jupyter authentication cookie via phishing, network interception, XSS in rendered notebook output, or access to browser storage on a compromised workstation.

AML.T0055

Failed Revocation

Victim or administrator resets the Jupyter Server password attempting incident containment; the non-rotating cookie secret renders this control ineffective without manual secret deletion.

AML.T0012

Persistent Re-entry

Adversary reuses the pre-reset cookie post-password change, gaining full authenticated access to the Jupyter environment that the organization believes was secured.

AML.T0091.000

AI Environment Exploitation

Adversary executes arbitrary code via notebooks, exfiltrates model weights, training data, and embedded API credentials, or injects malicious code into ML training pipelines.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Jupyter	pip	<= 2.17.0	`2.18.0`
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

6.8 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 22% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC High

PR Low

UI None

S Unchanged

C High

I High

A None

What should I do?

5 steps

Patch: Upgrade jupyter-server to 2.18.0+ which regenerates the cookie secret on password change.
Immediate workaround: rm ~/.local/share/jupyter/runtime/jupyter_cookie_secret followed by server restart to immediately invalidate all active sessions.
Detection: Review server access logs for sessions persisting across known password reset timestamps; any authenticated request using a cookie issued before a password change event is suspicious.
Architecture hardening: Place Jupyter behind JupyterHub or a reverse proxy with independent session management; restrict Jupyter access to localhost or VPN to reduce cookie interception surface.
For containerized environments: restart Jupyter containers after any suspected credential compromise to force secret regeneration.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

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

How is it classified?

Auth Bypass Data Extraction Framework API AML.T0012 - Valid Accounts AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15.1 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.5 - Information security in AI system design

NIST AI RMF

GOVERN-6.2 - Policies and procedures for AI risk management are in place MANAGE-2.4 - Residual risks to the organization from each AI system are managed

Frequently Asked Questions

What is CVE-2026-40934?

Jupyter Server versions up to 2.17.0 permanently store the cookie signing secret on disk and never rotate it, meaning authentication cookies captured before a password change remain cryptographically valid afterward — credential rotation does not revoke active sessions. With 1,862 downstream dependents, this flaw is embedded across a large footprint of data science and AI development infrastructure, where Jupyter typically serves as the central control plane for training pipelines, model development, and credential-laden notebooks. Exploitation probability is low (EPSS 0.065%, no public exploit, not in KEV), but the impact of a successful attack is severe: an adversary who captures a session cookie before a password reset can silently re-enter the environment after the team believes the incident was contained. Upgrade to jupyter-server 2.18.0 immediately; if patching is blocked, delete `~/.local/share/jupyter/runtime/jupyter_cookie_secret` and restart the server to force secret regeneration.

Is CVE-2026-40934 actively exploited?

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

How to fix CVE-2026-40934?

1. Patch: Upgrade jupyter-server to 2.18.0+ which regenerates the cookie secret on password change. 2. Immediate workaround: `rm ~/.local/share/jupyter/runtime/jupyter_cookie_secret` followed by server restart to immediately invalidate all active sessions. 3. Detection: Review server access logs for sessions persisting across known password reset timestamps; any authenticated request using a cookie issued before a password change event is suspicious. 4. Architecture hardening: Place Jupyter behind JupyterHub or a reverse proxy with independent session management; restrict Jupyter access to localhost or VPN to reduce cookie interception surface. 5. For containerized environments: restart Jupyter containers after any suspected credential compromise to force secret regeneration.

What systems are affected by CVE-2026-40934?

This vulnerability affects the following AI/ML architecture patterns: Jupyter notebook environments, ML development pipelines, Multi-user data science platforms, Training pipelines, Containerized AI development environments.

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

CVE-2026-40934 has a CVSS v3.1 base score of 6.8 (MEDIUM). The EPSS exploitation probability is 0.31%.

What is the AI security impact?

Affected AI Architectures

Jupyter notebook environmentsML development pipelinesMulti-user data science platformsTraining pipelinesContainerized AI development environments

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Art. 15.1

ISO 42001: A.6.1.5

NIST AI RMF: GOVERN-6.2, MANAGE-2.4

What are the technical details?

Original Advisory

## Summary A persistent cookie secret vulnerability allows authenticated users to maintain indefinite access even after password changes. The cookie secret used to sign authentication cookies is stored in a permanent file (`~/.local/share/jupyter/runtime/jupyter_cookie_secret`) that is never automatically rotated or cleared, allowing stolen or compromised cookies to remain valid indefinitely regardless of password resets. ## PoC - Start a Jupyter server with password authentication: `jupyter server password`, `jupyter server` - Log in with the password and capture the authentication cookie (e.g., just login with a browser). - Change the password to revoke access: `jupyter server password` - Restart the server - Use the old stolen cookie => remains valid and provides full authenticated access. ## Impact - All jupyter-server deployments using password authentication where security incidents may occur - Multi-user systems where one user's compromised session should be revocable by administrators - Shared or public-facing Jupyter servers where credential rotation is a security requirement - Any deployment where password changes are expected to revoke existing sessions ## Patches Jupyter Server 2.18+ ## Workaround ```bash rm ~/.local/share/jupyter/runtime/jupyter_cookie_secret # Then restart the server ```

Exploitation Scenario

An adversary targeting an AI research team steals a data scientist's Jupyter authentication cookie via a phishing-delivered browser extension, XSS vulnerability in rendered notebook HTML output, or network interception on a shared Wi-Fi network. The security team detects the compromise and resets the Jupyter password within hours, logging the incident as contained. Because the cookie signing secret in `~/.local/share/jupyter/runtime/jupyter_cookie_secret` is never rotated, the adversary's captured cookie remains valid. Days later, the adversary silently re-enters the Jupyter environment, accesses proprietary model training notebooks, exfiltrates cloud API credentials stored as environment variables, and modifies a training pipeline script to embed a backdoor in the next model version — the entire post-remediation intrusion goes undetected because the organization believes access was revoked.

Weaknesses (CWE)

CWE-613 Insufficient Session Expiration Primary

CWE-613 — Insufficient Session Expiration: According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."