Alerta de seguridad: dos vulnerabilidades críticas en n8n permiten ejecución remota de código y control total de instancias

Una pareja de fallos de seguridad recién descubiertos en la plataforma de automatización de flujos de trabajo n8n pueden permitir a un atacante tomar el control completo de instancias vulnerables, obtener datos confidenciales y ejecutar código arbitrario en el servidor que aloja la aplicación. Las debilidades, registradas como CVE-2026-1470 y CVE-2026-0863, fueron descubiertas por investigadores de la compañía DevSecOps JFrog y demuestran, una vez más, lo complejo que es aislar de forma segura lenguajes dinámicos dentro de entornos restringidos.

n8n es una herramienta de código abierto que facilita encadenar aplicaciones, APIs y servicios mediante un editor visual para crear procesos automatizados. Su popularidad crece cada día; por ejemplo, el paquete en npm supera las 200.000 descargas semanales, y su ecosistema soporta integraciones con servicios de inteligencia artificial y modelos de lenguaje. Esa adopción amplia hace que cualquier fallo sea especialmente relevante para empresas que dependen de automatizaciones internas o expuestas en internet.

La primera vulnerabilidad, CVE-2026-1470, es una forma de escape de sandbox en el motor JavaScript de n8n. A través de un manejo inadecuado de la sentencia with y una validación insuficiente de identificadores constructores, un atacante con capacidad para crear o modificar un flujo puede provocar que el sanitizador resuelva un identificador hasta la función global Function, lo que abre la puerta a la ejecución de código JavaScript arbitrario dentro del nodo principal de n8n. Pese a que se requiere autenticación para explotar este vector —es decir, se necesita permiso para editar workflows— JFrog subraya que el fallo merece una calificación crítica (9.9/10) porque usuarios con privilegios moderados, que en muchas instalaciones podrían no ser administradores, podrían escalar y controlar toda la infraestructura de n8n. Más detalles técnicos sobre este tipo de evasiones pueden hallarse en el informe de JFrog: Achieving Remote Code Execution on n8n via Sandbox Escape.

La segunda, CVE-2026-0863, afecta al entorno Python que n8n puede invocar como proceso auxiliar. En este caso los investigadores describen un escape del sandbox basado en el análisis sintáctico del código (AST) que combina la introspección mediante cadenas de formato con un comportamiento particular de Python 3.10+ relativo a excepciones y atributos. Esa combinación permite recuperar acceso a builtins restringidos e importaciones, y finalmente ejecutar comandos del sistema operativo cuando Python corre como subprocess en el nodo principal, lo que ocasiona igualmente ejecución remota de código a nivel del host.

Los hallazgos de JFrog ponen sobre la mesa una lección recurrente: contener lenguajes como JavaScript y Python dentro de sandboxes seguros es extraordinariamente difícil. Incluso mecanismos que usan listas de bloqueo, varias capas de validación y transformaciones sobre el AST pueden fallar si no se contemplan todas las sutilezas del lenguaje y sus runtimes. En palabras de los autores del análisis, las características y comportamientos en tiempo de ejecución pueden aprovecharse para invalidar supuestos de seguridad, por lo que la defensa debe ser lo más profunda y conservadora posible.

n8n lanzó parches para ambas vulnerabilidades; CVE-2026-1470 se corrigió en las versiones 1.123.17, 2.4.5 y 2.5.1, mientras que CVE-2026-0863 quedó solucionada en 1.123.14, 2.3.5 y 2.4.2. Los usuarios que operan instancias autoalojadas deben actualizar sin demora a las versiones mencionadas o a versiones posteriores, ya que la plataforma en la nube de n8n ya ha aplicado las correcciones y no se ven afectadas las instancias gestionadas por el servicio. Para consultar las notas de lanzamiento y confirmar la disponibilidad del parche puedes revisar el repositorio oficial: n8n Releases en GitHub.

La investigadora Rhoda Smart ha publicado un análisis técnico centrado en CVE-2026-0863 y ha anunciado que añadirá un proof-of-concept en su entrada, algo que suele acelerar la búsqueda de instancias no parcheadas por parte de atacantes oportunistas. Su explicación técnica puede leerse en: CVE-2026-0863: Python sandbox escape in n8n, y es una lectura recomendable para administradores y equipos de seguridad que quieran entender el vector de ataque y validarlo en entornos controlados.

Estos incidentes se suman a vulnerabilidades previas que han afectado a n8n recientemente; un fallo de máxima severidad apodado "Ni8mare" permitió la toma de control remota de instancias locales sin autenticación, y los escaneos masivos mostraron inicialmente decenas de miles de despliegues expuestos. Aunque la cifra de instancias afectadas ha ido descendiendo, Shadowserver reportaba cerca de 39.900 instancias todavía accesibles a finales de enero, lo que refleja una tasa de parcheo lenta entre muchos operadores.

Si administras n8n en modalidad self-hosted conviene que, además de actualizar cuanto antes, revises las políticas de quién puede crear o modificar workflows, segmentes la red para minimizar el impacto de un posible compromiso, rote credenciales y secretos integrados en automatizaciones, y monitorices logs y actividad inusual en los nodos que ejecutan procesos externos. Realizar copias de seguridad previas a la actualización y validar las nuevas versiones en entornos de prueba también ayuda a evitar interrupciones operativas.

En definitiva, estas vulnerabilidades recuerdan que la flexibilidad de plataformas como n8n viene acompañada de una responsabilidad operativa importante: mantener infraestructuras actualizadas, aplicar principios de mínimo privilegio y supervisar activamente la exposición pública son medidas indispensables para no convertir una herramienta de productividad en un vector de riesgo para la organización.