What is the CVSS score of CVE-2026-40864?

CVE-2026-40864 has a CVSS 3.1 base score of 5.4 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-40864?

Yes, a patch is available for CVE-2026-40864. Update the affected software to the latest version immediately.

JupyterHub CVE-2026-40864

MEDIUM

Cross-Site Request Forgery (CSRF) (CWE-352)

2026-05-05 https://github.com/jupyterhub/jupyterhub

CSRF

5.4

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

5.4 MEDIUM

AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

May 05, 2026 - 19:01 vuln.today

Analysis Generated

May 05, 2026 - 19:01 vuln.today

DescriptionGitHub Advisory

Summary

JupyterHub's XSRF protection (updated in 4.1.0) inappropriately treated requests with Sec-Fetch-Mode: no-cors as same-origin requests, which they are not, bypassing XSRF checks. The JSON API is not affected, only HTTP form endpoints, such as /hub/spawn and /hub/accept-share, meaning attackers could trigger server spawn (but not access the server) and if the attacker is a JupyterHub user permitted to share access to their server, cause a user to accept a share and have access to the attacker's server.

Patches

Upgrade to JupyterHub 5.4.5.

Mitigations

If a reverse proxy is in use, drop requests to JupyterHub with Sec-Fetch-Mode: no-cors.

AnalysisAI

Cross-site request forgery (CSRF) in JupyterHub 4.1.0 through 5.4.4 bypasses XSRF protection for HTTP form endpoints by misclassifying requests with Sec-Fetch-Mode: no-cors as same-origin, allowing unauthenticated attackers to trigger server spawning or, if they are JupyterHub users with share permissions, coerce victims into accepting access shares to the attacker's server. The JSON API is not affected. No active exploitation confirmed, but CVSS 5.4 reflects moderate integrity and availability impact via user interaction.

Technical ContextAI

JupyterHub implements XSRF protection via token validation on state-changing HTTP form endpoints like /hub/spawn and /hub/accept-share. The vulnerability stems from CWE-352 (Cross-Site Request Forgery) introduced in version 4.1.0, where the XSRF check was modified to incorrectly treat cross-origin requests bearing Sec-Fetch-Mode: no-cors as same-origin requests. The Sec-Fetch-Mode header is part of the Fetch metadata request headers specification and should signal no-cors mode (used by HTML forms, image tags, etc.) as explicitly cross-origin. By mishandling this signal, JupyterHub allowed form-based POST requests from attacker-controlled sites to bypass token validation. The vulnerability affects Python package jupyterhub (CPE: pkg:pip/jupyterhub) versions 4.1.0 through 5.4.4.

RemediationAI

Upgrade JupyterHub to version 5.4.5 or later, which corrects the Sec-Fetch-Mode handling in XSRF validation. The upgrade is performed via pip with the command: pip install --upgrade jupyterhub>=5.4.5. For organizations unable to patch immediately, implement the recommended mitigation by configuring a reverse proxy (nginx, Apache, HAProxy, etc.) to drop any requests to JupyterHub endpoints with the Sec-Fetch-Mode: no-cors header, which will block the attack vector while preserving legitimate same-origin form submissions. This mitigation has minimal side effects for normal users but should be validated in a staging environment to ensure no legitimate cross-origin requests are required by custom integrations. The patch reference is https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-m68r-v472-jgq9.