Vulnerabilidades críticas en n8n: Ni8mare (CVE-2026-21858) y el riesgo para la automatización no-code

CyberSecureFox 🦊

La plataforma de automatización de flujos de trabajo n8n, ampliamente utilizada en entornos de DevOps e inteligencia artificial, se ha situado en el centro de la atención tras la divulgación reciente de cuatro vulnerabilidades críticas, dos de ellas con una puntuación máxima de 10,0 en la escala CVSS. La más grave, denominada Ni8mare (CVE-2026-21858), permite el secuestro remoto de una instancia sin autenticación previa, lo que la convierte en una amenaza de primer nivel para cualquier organización que dependa de n8n.

n8n como objetivo de ataque: automatización, IA y secretos de alto valor

n8n es una plataforma no-code/low-code para diseñar workflows que integran aplicaciones, APIs y servicios mediante un constructor visual. Se ha consolidado como pieza clave en proyectos de orquestación de LLM, agentes de IA y pipelines RAG. Según datos del ecosistema, supera las 50 000 descargas semanales en npm y acumula más de 100 millones de descargas en Docker Hub, lo que amplía de forma significativa su superficie de exposición.

El riesgo principal radica en que una instancia típica de n8n concentra secretos críticos de la infraestructura: claves de API, tokens OAuth, credenciales de bases de datos, accesos a nubes públicas y secretos de CI/CD. Como señalan los investigadores de Cyera, comprometer n8n no implica solo perder una aplicación aislada, sino entregar “las llaves de todo” al atacante, facilitando el movimiento lateral hacia bases de datos, repositorios de código y pipelines de despliegue.

Ni8mare (CVE-2026-21858): explotación de webhooks a través de “Content-Type confusion”

La vulnerabilidad Ni8mare (CVSS 10.0) permite a un atacante no autenticado acceder a archivos en el servidor e incluso, en determinados escenarios, llegar a la ejecución remota de comandos (RCE). El vector de ataque se basa en formularios y webhooks maliciosos que explotan una condición de content-type confusion, es decir, un manejo incorrecto de los datos en función del encabezado Content-Type.

n8n utiliza dos mecanismos distintos para analizar las peticiones entrantes. Cuando el encabezado es multipart/form-data, se activa un parser específico que guarda los archivos cargados en directorios temporales con protección frente a path traversal (ataques que intentan leer archivos fuera de la ruta permitida). Para otros tipos, como application/json, se usa un parser estándar sin estas salvaguardas.

Los investigadores demostraron que, al enviar una petición con Content-Type: application/json pero incluyendo campos que n8n espera tratar como archivos, el atacante obtiene control completo sobre el objeto req.body.files. Esto permite manipular los metadatos, incluido el ruta del archivo. En la práctica, se puede forzar a n8n a leer cualquier archivo local del servidor —configuraciones, logs, bases de datos o claves de cifrado— y usar esa información para forjar cookies, saltarse la autenticación y escalar hasta RCE.

Según la información oficial, Ni8mare afecta a todas las compilaciones de n8n hasta la versión 1.65.0 incluida y se corrigió en n8n 1.121.0 (18 de noviembre de 2025). No existen mitigaciones completas más allá de la actualización: se recomienda restringir o deshabilitar los endpoints de webhooks y formularios expuestos públicamente hasta aplicar el parche.

Otras vulnerabilidades críticas en n8n: carga insegura, fuga de sandbox y RCE

CVE-2026-21877: carga de archivos sin restricciones y ejecución de código

La vulnerabilidad CVE-2026-21877 (CVSS 10.0) está relacionada con la gestión insegura de archivos cargados. Un usuario autenticado, bajo ciertas condiciones, puede subir y ejecutar código malicioso a través de n8n, conduciendo a la comprometida total de la instancia. El fallo afecta a las versiones de la 0.123.0 hasta antes de la 1.121.3, y se corrige en la versión 1.121.3. Mientras no se actualice, se recomienda deshabilitar el nodo Git y limitar el acceso a usuarios totalmente confiables, especialmente en entornos multiusuario o SaaS.

N8scape (CVE-2025-68668): escape de la sandbox de Python (Pyodide)

N8scape (CVE-2025-68668, CVSS 9.9) afecta al Python Code Node, que se ejecuta con Pyodide en una sandbox. Un usuario autenticado con permiso para crear o modificar workflows puede evadir los controles de aislamiento y ejecutar comandos en el sistema anfitrión con los privilegios del proceso de n8n. Están afectadas las versiones de la 1.0.0 hasta antes de la 2.0.0. En n8n 2.0.0 se activa por defecto una implementación nativa de Python basada en un task runner (introducida de forma opcional en la 1.111.0), que refuerza la separación entre el código ejecutado y el host.

CVE-2025-68613: control insuficiente del código dinámico (RCE)

El fallo CVE-2025-68613 (CVSS 9.9) se clasifica como improper control of dynamically-managed code resources. En ciertas configuraciones, usuarios autenticados pueden lograr ejecución remota de código. Las correcciones están disponibles en 1.120.4, 1.121.1 y 1.122.0. De acuerdo con datos de Censys, a finales de diciembre de 2025 existían más de 100 000 instalaciones potencialmente vulnerables, lo que subraya la magnitud del problema.

Exposición global de n8n e impacto en la infraestructura

Los escaneos de Censys identifican más de 26 000 hosts de n8n expuestos directamente a Internet. Los países con mayor concentración son Estados Unidos (7079), Alemania (4280), Francia (2655), Brasil (1347) y Singapur (1129). La cifra real es probablemente muy superior si se tienen en cuenta instancias detrás de VPN, proxies o arquitecturas de Zero Trust.

En la práctica, n8n actúa como “bus” de integración entre decenas de sistemas internos y servicios en la nube. Su compromiso ofrece a un atacante un punto de entrada privilegiado hacia toda la infraestructura DevOps y de IA: bases de datos, colas de mensajería, repositorios de código, orquestadores de contenedores y pipelines de CI/CD, alineándose con riesgos descritos en marcos como OWASP Top 10 (gestión de secretos, control de acceso y RCE).

Ante este escenario, se recomienda a administradores y equipos DevOps actualizar n8n con la máxima prioridad. Como mínimo, se aconseja llegar a la versión 1.121.3 para mitigar Ni8mare y CVE-2026-21877, y a la 2.0.0 para cerrar N8scape, verificando además la aplicación de los parches para CVE-2025-68613. Adicionalmente, es fundamental no exponer n8n directamente a Internet (ubicándolo tras VPN, reverse proxy o pasarelas Zero Trust), habilitar autenticación obligatoria en todos los webhooks y formularios, aplicar el principio de mínimo privilegio en roles y permisos, y rotar periódicamente los secretos almacenados. La inclusión de auditorías periódicas de configuración, pruebas de penetración focalizadas en plataformas de automatización y monitorización de workflows sospechosos ayudará a reducir significativamente la probabilidad de que la próxima campaña de ataques comience por n8n u otras herramientas no-code críticas.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.