romain-deperne/cve-2026-40864Prueba de concepto para CVE-2026-40864: omisión de XSRF en JupyterHub mediante un POST de formulario de origen cruzado que explota Sec-Fetch-Mode: no-cors. Incluye HTML de PoC, análisis de la causa raíz y cronología de la divulgación.
Sec-Fetch-Mode: no-cors)Gravedad: Media (CVSS 5.4)
CWE: CWE-352 — Cross-Site Request Forgery (XSRF)
Afecta a: jupyterhub 4.1.0 ≤ versión < 5.4.5 (corregido en 5.4.5)
Aviso: GHSA-m68r-v472-jgq9
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-40864
Crédito: Romain Deperne
La protección XSRF de JupyterHub (reelaborada en 4.1.0) utilizaba la cabecera de petición Sec-Fetch-Mode para decidir
si una petición era del mismo origen. Trataba Sec-Fetch-Mode: no-cors como del mismo origen — pero
no-cors es exactamente lo que un navegador envía para un envío de formulario "simple" de origen cruzado. Como
resultado, los POST de formularios HTML de origen cruzado a los endpoints de formulario del Hub (/hub/spawn, /hub/accept-share)
omitían por completo la comprobación XSRF.
La API JSON no se ve afectada (requiere un tipo de contenido no simple, lo que fuerza una verificación previa CORS). Solo los endpoints de formulario HTML son alcanzables de esta forma.
La lógica XSRF cortocircuita a "confiable" para un conjunto de estados Sec-Fetch-* destinados a capturar
navegaciones del mismo origen. Sec-Fetch-Mode: no-cors estaba incluido en ese conjunto de confianza. Pero no-cors
es el modo que el navegador asigna a un simple <form method=POST> que se envía a un origen diferente —
precisamente el vector CSRF clásico que el token debería detener. Por lo tanto, cualquier endpoint que cambia estado y que
acepta un cuerpo de formulario simple, y depende únicamente de esta puerta XSRF, es falsificable desde un origen cruzado.
Llevando eso a endpoints reales: /hub/spawn (iniciar el servidor de la víctima) y /hub/accept-share
(hacer que la víctima acepte una compartición del servidor del atacante) son ambos POST de formulario detrás de esta puerta.
/hub/spawn — una página del atacante puede iniciar el servidor de usuario único de la víctima sin consentimiento
(consumo de recursos / estado inesperado; el atacante no obtiene acceso a ese servidor)./hub/accept-share — cuando el atacante es un usuario de JupyterHub autorizado a compartir su propio
servidor, puede forzar a una víctima a aceptar una compartición, dándole acceso al servidor del atacante
(un paso de preparación para escenarios posteriores de ingeniería social / colocación de datos).Usar Sec-Fetch-Mode como oráculo de origen no es sólido: no-cors no implica mismo origen. La corrección
en 5.4.5 deja de confiar en no-cors como mismo origen. Los operadores que no puedan actualizar de inmediato pueden descartar
las peticiones que lleven Sec-Fetch-Mode: no-cors en el proxy inverso.
poc/csrf_spawn.html — alójalo en cualquier origen del atacante y haz que un usuario de JupyterHub con sesión iniciada lo abra.
El formulario de envío automático emite un POST de origen cruzado a /hub/spawn (el navegador envía
Sec-Fetch-Mode: no-cors); las compilaciones vulnerables lo aceptan sin un token _xsrf válido e inician el
servidor de la víctima. Apunta action a /hub/accept-share para la variante de aceptación de compartición.
1. Edit TARGET-JUPYTERHUB in poc/csrf_spawn.html
2. Serve the file from an attacker origin (any static host)
3. Open it in a browser already authenticated to the target Hub
4. Observe the victim's server spawn with no XSRF token supplied
Divulgado de forma responsable. PoC publicado después de que se distribuyera la corrección.