CVE-2026-40934: Jupyter Server Auth Bypass Vulnerability

CVE-2026-40934 Overview

CVE-2026-40934 is an insufficient session expiration vulnerability [CWE-613] in Jupyter Server, the backend for Jupyter web applications. Versions 2.17.0 and earlier persist the cookie-signing secret to a static file at ~/.local/share/jupyter/runtime/jupyter_cookie_secret. The secret is never rotated when a user changes their password. Authentication cookies issued before a password reset remain cryptographically valid after the reset and a server restart. An attacker who captured a session cookie retains full authenticated access regardless of subsequent credential changes. The issue is fixed in Jupyter Server version 2.18.0.

Critical Impact

Stolen Jupyter Server session cookies remain valid after password resets, allowing attackers to maintain authenticated access to shared or public-facing notebook servers.

Affected Products

• Jupyter Server versions 2.17.0 and earlier
• Deployments using password-based authentication
• Shared and public-facing Jupyter Server instances

Discovery Timeline

• 2026-05-05 - CVE-2026-40934 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-40934

Vulnerability Analysis

Jupyter Server signs authentication cookies using a secret stored in ~/.local/share/jupyter/runtime/jupyter_cookie_secret. The file persists across server restarts so users do not need to re-authenticate after routine maintenance. The flaw is that the signing key is treated as a long-lived server identity rather than a credential bound to the authentication state.

When an administrator or user changes the Jupyter Server password, the application updates the password hash but does not regenerate the cookie secret. Existing signed cookies continue to validate against the unchanged key. The server has no session table to invalidate, because authentication state is encoded entirely inside the cookie signature.

This breaks the security expectation that password rotation revokes active sessions. Operators rotating credentials in response to suspected compromise gain no protection from the rotation itself.

Root Cause

The root cause is an absent binding between the cookie-signing secret and the password lifecycle. The secret is generated once on first run and reused indefinitely. The password change handler does not invoke secret rotation, and there is no server-side session store that could be flushed as an alternative invalidation path [CWE-613].

Attack Vector

An attacker first obtains a valid Jupyter Server session cookie. Capture vectors include cross-site scripting in notebook content, network interception on non-TLS deployments, malicious browser extensions, or access to a previously authenticated workstation. The user or administrator then rotates the Jupyter password, expecting active sessions to be terminated.

The attacker replays the captured cookie against the server. Because the signing secret in jupyter_cookie_secret is unchanged, the cookie validates and the attacker regains full notebook execution privileges. This grants arbitrary code execution in the user's runtime environment with access to mounted data and credentials.

The vulnerability requires low-privilege prior access to a session cookie but no further user interaction once the cookie is captured.

Detection Methods for CVE-2026-40934

Indicators of Compromise

• Authentication events from unexpected source IP addresses immediately following a password change
• Reuse of session cookies that predate the password reset timestamp
• Notebook kernel execution originating from sessions not tied to a recent login event
• Unchanged modification timestamp on ~/.local/share/jupyter/runtime/jupyter_cookie_secret after a password rotation

Detection Strategies

• Correlate Jupyter Server access logs with password change events to identify post-rotation activity from pre-rotation sessions
• Monitor file integrity of jupyter_cookie_secret and alert when the file age exceeds the most recent password change
• Inspect web proxy or reverse proxy logs for cookie values reused across long time windows on shared hosts

Monitoring Recommendations

• Enable verbose authentication logging in Jupyter Server and forward logs to a centralized analytics platform
• Track concurrent session counts per user account and alert on anomalies after credential rotations
• Audit the Jupyter runtime directory permissions to ensure the cookie secret is not readable by other local users

How to Mitigate CVE-2026-40934

Immediate Actions Required

• Upgrade Jupyter Server to version 2.18.0 or later on all hosts running password-based authentication
• After upgrading, manually delete ~/.local/share/jupyter/runtime/jupyter_cookie_secret and restart the server to force regeneration of the signing key
• Force all users to re-authenticate following the upgrade and rotate any passwords suspected of prior exposure
• Review access logs for the period since the last password reset and investigate any sessions that survived rotation

Patch Information

The Jupyter Server maintainers released the fix in version 2.18.0. The patch ensures the cookie-signing secret is rotated when a password change occurs, invalidating previously issued authentication cookies. Refer to the Jupyter Server GitHub Security Advisory GHSA-5mrq-x3x5-8v8f for the official disclosure.

Workarounds

• Delete jupyter_cookie_secret and restart Jupyter Server whenever a password is changed, until the upgrade is applied
• Replace password-based authentication with token-based or external identity provider authentication on public-facing deployments
• Restrict Jupyter Server exposure behind a reverse proxy that enforces independent session management and short-lived tokens

# Configuration example - manual secret rotation after password change
systemctl stop jupyter-server
rm -f ~/.local/share/jupyter/runtime/jupyter_cookie_secret
systemctl start jupyter-server