romain-deperne/CVE-2026-40864
GitHub: romain-deperne/CVE-2026-40864
该项目披露并复现了 JupyterHub 因错误信任 `Sec-Fetch-Mode: no-cors` 而导致 XSRF 防护被跨域表单 POST 绕过的漏洞(CVE-2026-40864),附带概念验证代码及修复与缓解指引。
Stars: 0 | Forks: 0
# CVE-2026-40864 — 通过跨域表单 POST 绕过 JupyterHub XSRF (`Sec-Fetch-Mode: no-cors`)
**严重程度**:中等
**CWE**:CWE-352 — 跨站请求伪造 (XSRF)
**受影响版本**:`jupyterhub` 4.1.0 ≤ version < 5.4.5(已在 **5.4.5** 中修复)
**安全公告**:[GHSA-m68r-v472-jgq9](https://github.com/advisories/GHSA-m68r-v472-jgq9)
**NVD**:https://nvd.nist.gov/vuln/detail/CVE-2026-40864
**致谢**:Romain Deperne
## TL;DR
JupyterHub 的 XSRF 防护(在 4.1.0 中经过重新设计)使用 `Sec-Fetch-Mode` 请求头来判断请求是否同源。它将 `Sec-Fetch-Mode: no-cors` 视为同源请求——但是 `no-cors` 恰恰是浏览器在发送**跨域“简单”表单提交**时所使用的模式。因此,发往 Hub 表单端点(`/hub/spawn`、`/hub/accept-share`)的跨域 HTML 表单 POST 请求完全绕过了 XSRF 检查。
JSON API 不受此影响(它要求使用非简单内容类型,这会强制触发 CORS preflight)。只有 HTML 表单端点会以这种方式被访问到。
## 发现过程
XSRF 逻辑会直接短路判定为“受信任”,前提是请求包含一组旨在匹配同源导航的 `Sec-Fetch-*` 状态。`Sec-Fetch-Mode: no-cors` 被包含在这个受信任的集合中。但是 `no-cors` 是浏览器为发送到不同源的普通 `
标签:JupyterHub, XSRF绕过, 后端开发, 多模态安全, 数据可视化, 漏洞分析, 跨站请求伪造, 路径探测, 逆向工具