CVE-2026-40864: JupyterHub CSRF Vulnerability

CVE-2026-40864 Overview

CVE-2026-40864 is a Cross-Site Request Forgery (CSRF/XSRF) vulnerability in JupyterHub, the multi-user server software for Jupyter notebooks. The flaw affects versions 4.1.0 through 5.4.4. JupyterHub's XSRF protection logic incorrectly treats requests carrying the Sec-Fetch-Mode: no-cors header as same-origin requests, bypassing XSRF checks on HTTP form endpoints. Attackers can abuse endpoints such as /hub/spawn and /hub/accept-share to trigger server spawn or coerce users into accepting share invitations to an attacker-controlled server. The JSON API is not affected. Maintainers released a fix in version 5.4.5.

Critical Impact
Attackers can bypass XSRF protections to trigger user server spawning or force users to accept access to an attacker's JupyterHub server, enabling unauthorized cross-account interactions when victims visit attacker-controlled web content.

Affected Products

JupyterHub versions 4.1.0 through 5.4.4
HTTP form endpoints including /hub/spawn and /hub/accept-share
Deployments without a reverse proxy filtering Sec-Fetch-Mode: no-cors requests

Discovery Timeline

2026-05-22 - CVE-2026-40864 published to NVD
2026-05-26 - Last updated in NVD database

Technical Details for CVE-2026-40864

Vulnerability Analysis

The vulnerability is a Cross-Site Request Forgery flaw classified under [CWE-352]. JupyterHub refreshed its XSRF protection in version 4.1.0 and introduced an exemption path for browser requests deemed safe based on the Sec-Fetch-Mode header. The exemption incorrectly included the value no-cors, which browsers attach to several cross-site request types such as those initiated by HTML form submissions, image loads, and certain script-driven fetches. As a result, attacker-controlled pages can issue cross-origin requests against JupyterHub form endpoints without supplying a valid XSRF token. Exploitation requires user interaction, namely visiting a malicious page while authenticated to JupyterHub.

Root Cause

The get_xsrf_token check inside jupyterhub/_xsrf_utils.py short-circuits XSRF validation when the fetch mode equals websocket or no-cors. Treating no-cors as same-origin removes the protection it was designed to enforce, because browsers send Sec-Fetch-Mode: no-cors for many cross-site requests. The patch removes no-cors from the exemption set.

Attack Vector

An attacker hosts a page that submits a forged form (or similar no-cors request) targeting a victim's authenticated JupyterHub session. The browser attaches authentication cookies, JupyterHub skips XSRF validation, and the request executes. The attacker can force a victim to spawn a notebook server or accept a share invitation that grants the attacker access to the victim's server interface, depending on configuration. The attacker cannot directly read responses due to the same-origin policy but can drive state-changing actions.

python

         return False
 
     fetch_mode = handler.request.headers.get("Sec-Fetch-Mode", "unspecified")
-    if fetch_mode in {"websocket", "no-cors"} or (
+    if fetch_mode == "websocket" or (
         fetch_mode in {"navigate", "unspecified"}
         and handler.request.method.lower() in {"get", "head", "options"}
     ):

Source: JupyterHub commit 9c5ec277 — the patch removes no-cors from the XSRF check bypass set, forcing those requests through standard XSRF validation.

Detection Methods for CVE-2026-40864

Indicators of Compromise

Unexpected POST requests to /hub/spawn or /hub/accept-share with Sec-Fetch-Mode: no-cors and a cross-site Referer or Origin header.
New JupyterHub server spawn events for users immediately following navigation to external URLs in proxy or browser logs.
Unsolicited share-acceptance events tied to user sessions that did not interact with the share UI.

Detection Strategies

Inspect JupyterHub access logs and reverse proxy logs for form-endpoint requests carrying Sec-Fetch-Mode: no-cors together with Sec-Fetch-Site: cross-site.
Correlate spawn and share-acceptance audit events with browser-side referrer data to flag activity originating from non-JupyterHub origins.
Alert on bursts of spawn requests across multiple user accounts within short time windows, which may indicate a campaign targeting authenticated sessions.

Monitoring Recommendations

Enable verbose request logging on the reverse proxy fronting JupyterHub and forward logs to a centralized analytics platform.
Track JupyterHub version metadata across deployments to confirm all nodes run 5.4.5 or later.
Monitor the accept-share workflow specifically, as it is the highest-impact endpoint exposed by this vulnerability.

How to Mitigate CVE-2026-40864

Immediate Actions Required

Upgrade JupyterHub to version 5.4.5 or later on all hub nodes.
If immediate upgrade is not possible, configure the reverse proxy to drop requests to JupyterHub that contain Sec-Fetch-Mode: no-cors.
Audit recent spawn and share-acceptance events for anomalous activity that may predate the fix.

Patch Information

The issue is fixed in JupyterHub 5.4.5. The fix removes no-cors from the XSRF exemption list in jupyterhub/_xsrf_utils.py, ensuring that no-cors requests are subject to full XSRF token validation. See the GitHub Security Advisory GHSA-m68r-v472-jgq9 and the upstream commit for technical detail.

Workarounds

Drop or reject requests to JupyterHub at the reverse proxy when the Sec-Fetch-Mode header equals no-cors.
Restrict the share permission so fewer users can issue share invitations until patching completes.
Educate users about phishing pages that may attempt to coerce browser-driven requests to authenticated JupyterHub sessions.

bash

# Example NGINX snippet to drop no-cors requests to JupyterHub
map $http_sec_fetch_mode $block_nocors {
    default 0;
    "no-cors" 1;
}

server {
    listen 443 ssl;
    server_name jupyterhub.example.com;

    if ($block_nocors) {
        return 403;
    }

    location / {
        proxy_pass http://jupyterhub_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}