CVE-2026-40864: 
Wolfi vulnerability analysis and mitigation

CVE-2026-40864 is a Cross-Site Request Forgery (CSRF/XSRF) bypass vulnerability in JupyterHub, a multi-user server for Jupyter notebooks. The flaw affects versions 4.1.0 through 5.4.4, where XSRF protection incorrectly treated HTTP requests bearing the Sec-Fetch-Mode: no-cors header as same-origin requests, effectively bypassing CSRF checks on HTTP form endpoints. It was discovered by researcher romain-deperne and published on May 5, 2026, with a fix released in version 5.4.5. The vulnerability carries a CVSS v3.1 base score of 5.4 (Moderate) per the GitHub Advisory, or 4.3 (Medium) per NVD scoring (Github Advisory, JupyterHub Advisory).

The root cause is classified as CWE-352 (Cross-Site Request Forgery). The XSRF protection logic introduced in JupyterHub 4.1.0 contained a flaw in jupyterhub/_xsrf_utils.py where the Sec-Fetch-Mode: no-cors value was grouped with websocket as a condition to skip XSRF token validation — incorrectly treating cross-origin no-cors requests as trusted same-origin requests. The fix (commit 9c5ec27) removes no-cors from the bypass condition, so only websocket and safe HTTP methods (GET, HEAD, OPTIONS) with navigate or unspecified fetch modes skip the XSRF check. Only HTTP form endpoints are affected — specifically /hub/spawn and /hub/accept-share — while the JSON API is not vulnerable (JupyterHub Commit, Github Advisory).

Exploitation allows an unauthenticated network attacker (with required user interaction) to trigger server spawn operations on behalf of a victim JupyterHub user. More critically, if the attacker is themselves an authenticated JupyterHub user with share permissions, they can craft a cross-origin form POST to /hub/accept-share that tricks a victim into accepting a malicious share request, granting the attacker access to the victim's Jupyter server environment and any data or notebooks it contains. There is no direct confidentiality impact from the CSRF bypass alone, but the share-acceptance scenario could expose sensitive research data, credentials, or code stored in the victim's server (Github Advisory, JupyterHub Advisory).

1. Reconnaissance: Identify a JupyterHub instance running versions 4.1.0–5.4.4 that is accessible to the target user. Determine whether the target user is authenticated to JupyterHub.
2. Craft malicious page: Create an attacker-controlled web page containing an HTML form that targets a vulnerable JupyterHub endpoint (e.g., /hub/spawn or /hub/accept-share) and is configured to submit cross-origin with no-cors fetch mode (e.g., using fetch() with mode: 'no-cors' or a standard HTML form POST, which browsers send with Sec-Fetch-Mode: no-cors).
3. Lure victim: Trick the authenticated JupyterHub user into visiting the malicious page (e.g., via phishing email or malicious link), causing their browser to automatically submit the cross-origin form POST to the JupyterHub endpoint.
4. Bypass XSRF check: The JupyterHub server receives the request with Sec-Fetch-Mode: no-cors and, due to the vulnerability, skips the XSRF token validation, processing the forged request as legitimate.
5. Achieve objective: For /hub/spawn, the victim's server is spawned without their intent. For /hub/accept-share (requires attacker to be a JupyterHub user with share permissions), the victim accepts a share from the attacker, granting the attacker access to the victim's Jupyter server environment (JupyterHub Advisory, JupyterHub Commit).

• Network: Unexpected HTTP POST requests to /hub/spawn or /hub/accept-share originating from unusual referrer domains or with Sec-Fetch-Mode: no-cors and a cross-origin Origin header not matching the JupyterHub host.
• Logs: JupyterHub access logs showing form POST requests to /hub/spawn or /hub/accept-share from authenticated users at unusual times or from unexpected IP addresses; log entries showing share acceptance events (accept-share) not initiated by the user.
• Application State: Unexpected server spawn events for users who did not initiate them; unexpected share relationships appearing in JupyterHub admin panel between users who did not intentionally establish them.

Upgrade JupyterHub to version 5.4.5 or later, which corrects the XSRF bypass by removing no-cors from the set of fetch modes that skip XSRF validation. As a temporary workaround for deployments using a reverse proxy (e.g., nginx, Apache, Traefik), configure the proxy to drop or reject incoming requests to JupyterHub that contain the Sec-Fetch-Mode: no-cors header. Deployments not using a reverse proxy should prioritize upgrading immediately (Github Advisory, JupyterHub Advisory).