JupyterHub Cross-Origin Form POST XSRF Bypass (CVE-2026-40864)

Metadata

Affected Target

Summary

JupyterHub’s XSRF protection, reworked in 4.1.0, uses the browser-supplied Sec-Fetch-Mode header as an origin oracle to decide whether a request is same-origin and therefore exempt from token validation. The implementation incorrectly treats Sec-Fetch-Mode: no-cors as a same-origin signal, but browsers send exactly that mode for a plain cross-origin <form method="POST"> submission — the textbook CSRF vector the token exists to stop. As a result, the Hub’s HTML form endpoints (/hub/spawn and /hub/accept-share) can be forged from any external origin with no valid _xsrf token. The JSON API is unaffected because it requires a non-simple content type that forces a CORS preflight. The included PoC is a self-submitting HTML form that demonstrates the bypass against /hub/spawn.

Vulnerability Details

Root Cause

The XSRF check short-circuits to “trusted” whenever Sec-Fetch-Mode is no-cors, but no-cors does not imply same-origin — it is precisely the mode assigned to a simple cross-origin form POST, so the same-origin assumption underlying the check is unsound.

Attack Vector

1. Attacker hosts an auto-submitting HTML page containing a hidden <form> targeting the victim’s JupyterHub instance (/hub/spawn or /hub/accept-share).
2. Attacker lures a logged-in JupyterHub user into visiting the page.
3. The browser issues the cross-origin POST with Sec-Fetch-Mode: no-cors; the victim’s session cookie is sent automatically.
4. Vulnerable JupyterHub accepts the request without a valid _xsrf token, executing the action as the victim.

Impact

An attacker can force a victim to spawn their own single-user server without consent (resource abuse / unexpected state), or — for /hub/accept-share — force the victim to accept a share of the attacker’s server, which can be used to stage further social-engineering or data-exfiltration scenarios.

Environment / Lab Setup

Target:   JupyterHub 4.1.0 – 5.4.4 (self-hosted or containerized instance)
Attacker: Any static file host or local HTTP server to serve csrf_spawn.html; a browser session already authenticated to the target Hub

Proof of Concept

PoC Script

See csrf_spawn.html in this folder.

1

python3 -m http.server 8000   # serve csrf_spawn.html from an attacker-controlled origin

The page auto-submits a hidden form (with an empty _xsrf field) to the target Hub’s /hub/spawn endpoint the moment it loads. Because the browser sends Sec-Fetch-Mode: no-cors for this simple form POST, vulnerable JupyterHub builds treat it as same-origin and process the spawn request without a valid token. Editing the action attribute to /hub/accept-share demonstrates the share-acceptance variant.

Detection & Indicators of Compromise

Signs of compromise:

• Server spawn events in JupyterHub audit logs with no corresponding user-initiated UI action
• Unexpected accept-share events granting access to servers the victim did not intend to use
• Requests to /hub/spawn or /hub/accept-share carrying Sec-Fetch-Mode: no-cors and a foreign Origin/Referer

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/romain-deperne/CVE-2026-40864 on 2026-07-05.