Vulnerabilidades críticas en n8n que permiten la ejecución de código desde formularios públicos

Investigadores de ciberseguridad han sacado a la luz varias vulnerabilidades críticas en n8n, la plataforma de automatización de flujos de trabajo, que han sido corregidas en las últimas entregas del proyecto. Los fallos permiten desde la ejecución remota de comandos hasta la evaluación de expresiones sin autenticación a través de formularios públicos, y ponen en riesgo tanto instalaciones autogestionadas como despliegues en la nube.

Dos de las fallas más graves se corresponden con los identificadores CVE-2026-27577 y CVE-2026-27493. La primera constituye una ruptura del aislamiento en el compilador de expresiones: un caso que no fue tratado dentro del reescritor del árbol de sintaxis abstracta permite que ciertas expresiones se ejecuten sin la transformación de seguridad esperada, abriendo la puerta a la ejecución de comandos en el servidor cuando un usuario con permisos suficientes crea o modifica un flujo. La segunda aprovecha el funcionamiento público de los endpoints de formularios de n8n: un mecanismo de doble evaluación en los nodos de formulario puede permitir que un atacante inyecte expresiones maliciosas sin necesidad de autenticarse, por ejemplo empleando un formulario de contacto expuesto.

La combinación de ambas fallas puede ser especialmente peligrosa: la evaluación no autenticada de una expresión en un formulario pública puede encadenarse con un escape del sandbox de expresiones para alcanzar ejecución de código en el host que corre n8n. Investigadores de Pillar Security demostraron escenarios en los que bastaba con introducir una carga en el campo "Nombre" de un formulario para ejecutar comandos en el sistema afectado.

Además de esos vectores, los mantenedores de n8n han corregido dos vulnerabilidades críticas adicionales que también podían desembocar en ejecución arbitraria de código: CVE-2026-27495, relacionada con el sandbox del ejecutor de tareas JavaScript, y CVE-2026-27497, que afecta al modo de consulta SQL del nodo Merge y permitía escribir archivos arbitrarios en el servidor.

Las versiones afectadas abarcan ramas anteriores y medias del proyecto: versiones anteriores a 1.123.22, la serie 2.0.0 hasta 2.9.2, y la serie 2.10.0 hasta 2.10.0 inclusive. Los parches están disponibles en 1.123.22, 2.9.3 y 2.10.1. Los avisos oficiales y los detalles técnicos pueden consultarse en los repositorios de seguridad del proyecto en GitHub y en el análisis de los descubridores; para más contexto técnico y medidas concretas, revisa las entradas en los enlaces de la propia comunidad: la nota de seguridad de n8n en GitHub y el informe de Pillar Security.

El riesgo práctico es alto porque, además de ejecutar código, un atacante con éxito podría acceder a la variable de entorno que n8n usa para cifrar credenciales (N8N_ENCRYPTION_KEY) y, con ello, descifrar tokens, claves de AWS, contraseñas de bases de datos y otros secretos guardados en la instancia. Por ese motivo, la explotación no solo permite control del servidor, sino también el compromiso de integraciones y servicios conectados desde los flujos.

Si administrar la actualización inmediata no es viable, n8n recomienda reducir la superficie de exposición: restringir quién puede crear y editar flujos —limitando esos permisos a personal de plena confianza—, ejecutar n8n en entornos con privilegios de sistema reducidos y controles de red estrictos, y aplicar mitigaciones puntuales sobre los nodos vulnerables. Entre las acciones temporales sugeridas figuran la exclusión de los nodos de formulario (n8n-nodes-base.form y n8n-nodes-base.formTrigger) mediante la variable de entorno NODES_EXCLUDE, el uso del modo de runners externos (N8N_RUNNERS_MODE=external) para acotar el alcance del ejecutor JavaScript y la desactivación del nodo Merge si procede. Los desarrolladores de n8n recuerdan que estas son soluciones provisionales y no sustituyen la instalación de los parches oficiales.

Para operadores preocupados por la integridad de sus entornos, además de aplicar las actualizaciones, es aconsejable auditar el uso de nodos de formulario y las rutas públicas expuestas, rotar claves y secretos si se sospecha compromiso, revisar logs y actividad inusual y fortalecer la segmentación de red y las políticas de acceso alrededor del servidor de n8n. La consulta de registros y la búsqueda de ejecuciones inesperadas de comandos o modificaciones de workflows son pasos prácticos para detectar intentos de explotación.

Aunque no hay informes públicos de explotación masiva en entornos productivos hasta el momento, la gravedad de los fallos y la facilidad de aprovechamiento en escenarios con formularios públicos hacen que la actualización inmediata sea la recomendación principal. Puedes leer las correcciones en los avisos oficiales de n8n en GitHub y seguir el análisis técnico en el informe de Pillar Security para comprender mejor las cadenas de ataque y los indicadores de compromiso.

Enlaces útiles para profundizar: explicación y parches en las advisories de GitHub sobre CVE-2026-27577 y CVE-2026-27493, análisis de Pillar Security sobre la explotación vía formularios aquí, y las otras correcciones vinculadas en los avisos de seguridad del proyecto: CVE-2026-27495 y CVE-2026-27497. Para referencias de vulnerabilidades públicas, revisa la entrada correspondiente en el inventario de NIST/NVD cuando esté disponible: https://nvd.nist.gov.

En resumen, la lección para administradores y equipos de seguridad es clara: ante sistemas que permiten ejecutar lógica o código en tiempo de ejecución, la combinación de endpoints públicos y sandboxes incompletos es un vector crítico. Aplicar parches, reducir permisos y eliminar nodos innecesarios son medidas inmediatas que reducen el riesgo mientras se completa una respuesta más amplia.