Acceso a claves API, contraseñas y a toda la infraestructura — todo sin contraseña: qué se sabe sobre la vulnerabilidad 10/10 en n8n
Especialistas muestran cómo los formularios de n8n permiten leer cualquier archivo en el servidor.
En la popular plataforma para la automatización de flujos de trabajo n8n se ha descubierto una vulnerabilidad crítica, que permite comprometer una instancia vulnerable sin inicio de sesión ni contraseña. Basta con enviar una solicitud especialmente formada, y el atacante puede extraer secretos, falsificar el acceso de administrador y, si la explotación evoluciona, ejecutar comandos en el servidor.
El problema recibió el identificador CVE-2026-21858 (puntuación CVSS: 10.0) y el nombre Ni8mare – así lo bautizó Cyera Research Labs. Según n8n, la vulnerabilidad permite leer archivos en el servidor mediante la ejecución de determinados workflow relacionados con formularios. Si en una organización esos formularios se usan para subir datos y su posterior procesamiento, el riesgo es especialmente grave: el atacante puede "colocar" en el sistema no el archivo subido, sino cualquier archivo local arbitrario del disco y forzar a la cadena de procesamiento a transmitir su contenido.
Cabe destacar que esta es ya la cuarta vulnerabilidad crítica en n8n conocida en las últimas dos semanas. Anteriormente la empresa divulgó CVE-2025-68613 (riesgo de ejecución remota de código —RCE— para usuarios autenticados en ciertas condiciones), CVE-2025-68668 (N8scape —omisión de la sandbox que permite ejecutar comandos en el host si se tienen permisos para crear/editar workflow) y CVE-2026-21877 (una carga de archivos peligrosa que conduce a la compromisión de la instancia). A diferencia de esas, la nueva CVE-2026-21858 no requiere credenciales y se basa en la confusión alrededor del encabezado Content-Type.
Técnicamente el problema está relacionado con la forma en que n8n analiza las solicitudes entrantes de webhooks y formularios. Al recibir una solicitud, la plataforma mira el Content-Type y elige un manejador: si es multipart/form-data, se activa el analizador de subida de archivos; si no, el analizador normal del cuerpo de la solicitud. Aquí comienza lo más importante: en un caso el resultado va a la estructura donde se esperan archivos (req.body.files), en el otro al cuerpo normal (req.body). Los investigadores de Cyera encontraron un escenario vulnerable en el manejador de envío de formularios: allí se invoca la función que trabaja con archivos, pero antes no se comprueba que el Content-Type sea realmente multipart/form-data. Como resultado, el atacante puede él mismo "construir" el objeto req.body.files y controlar el parámetro de la ruta del archivo.
El sentido práctico es simple: en lugar de copiar el archivo realmente subido, el atacante obliga al sistema a copiar cualquier archivo local del servidor. Y luego cualquier paso siguiente del workflow recibe el contenido de ese archivo como si fuera una "subida normal de usuario". A partir de ahí es cuestión de imaginación y de configuración: se pueden leer configuraciones, claves, tokens y la base de datos.
Uno de los escenarios descritos resulta especialmente plausible. Imagine un sitio con una interfaz de chat que responde preguntas sobre productos basándose en archivos de especificaciones subidos mediante Form-workflow a la base de conocimientos. En ese caso el atacante puede, mediante lectura arbitraria, acceder a la base de datos de n8n (por ejemplo, database.sqlite), extraer de allí el identificador del administrador, el correo y el hash de la contraseña, luego leer el archivo de configuración con el secreto de cifrado, y después construir una sesión falsa y obtener acceso de administrador eludiendo la autenticación. Y cuando el panel de administración ya está en manos — solo queda añadir un workflow con el nodo Execute Command y obtener ejecución remota de código (RCE).
En Cyera subrayan que n8n a menudo se convierte en el almacén central de lo más valioso: claves API, tokens OAuth, accesos a bases de datos, nubes y servicios internos. Por eso la compromisión de una instancia puede convertirse al instante en acceso a la infraestructura.
La vulnerabilidad afecta a todas las versiones de n8n hasta e incluyendo la 1.65.0 y se corrigió en la 1.121.0 (lanzamiento del 18 de noviembre de 2025). Se recomienda a los usuarios actualizar urgentemente a la versión corregida o a una posterior, en lo posible no exponer n8n a Internet, habilitar autenticación obligatoria para todos los formularios y limitar temporalmente los endpoints públicos de webhook/form si no es posible actualizar rápidamente.