Alerta crítica: dos fallos en n8n permiten ejecución remota de código y podrían comprometer toda tu infraestructura

Investigadores de seguridad han identificado dos fallos graves en la plataforma de automatización de flujos n8n que permiten la ejecución remota de código en instancias vulnerables. Las debilidades fueron detectadas por el equipo de investigación de JFrog y, según la evaluación pública, una de ellas alcanza una puntuación casi máxima de severidad, por lo que cualquier despliegue sin parchear corre un riesgo elevado de compromiso.

Los problemas reportados son vulnerabilidades de tipo eval injection, es decir, vectores que permiten que código dinámico enviado por un usuario autenticado sea interpretado y ejecutado por el entorno de n8n. En un caso la inyección compromete el mecanismo que n8n emplea para evaluar expresiones en JavaScript, sorteando las restricciones del sandbox y permitiendo ejecutar comandos con el contexto del proceso principal. En el otro, la debilidad afecta al componente encargado de ejecutar tareas en Python (python-task-executor), posibilitando que instrucciones Python arbitrarias se ejecuten sobre el sistema subyacente.

Las dos fallas han sido registradas en el catálogo de vulnerabilidades del NIST con los identificadores CVE-2026-1470 (con una valoración muy alta) y CVE-2026-0863. JFrog publica un análisis técnico detallado donde explican cómo se pudo realizar la evasión del sandbox y alcanzar ejecución remota; ese informe es una lectura recomendable para quien quiera comprender el vector de ataque y la cadena de explotación: análisis de JFrog.

El potencial impacto es amplio porque n8n se usa para automatizar tareas que muchas veces conectan servicios críticos: desde llaves y APIs de modelos de lenguaje hasta datos comerciales y sistemas de gestión de identidades. Si un atacante consigue ejecutar código en la instancia de n8n puede, en la práctica, obtener acceso transversal a esos recursos automatizados y a credenciales que estén almacenadas o que la propia plataforma pueda utilizar, lo que multiplicaría las consecuencias del incidente.

Un factor importante en esta historia es el modo de ejecución de n8n. En la documentación oficial se advierte que operar en modo interno (internal) para entornos de producción no ofrece el mismo grado de aislamiento que separar n8n del ejecutor de tareas (external mode). Cuando ambos componentes comparten procesos o permisos, una vulnerabilidad que logra escapar del sandbox puede alcanzar el nodo principal y, desde ahí, al resto de la infraestructura. Puedes consultar la explicación de n8n sobre la configuración de ejecutores en su documentación, y la descripción del sistema de expresiones en las páginas dedicadas a expresiones.

Estos hallazgos también reabren el debate sobre la dificultad de contener lenguajes dinámicos como JavaScript y Python en entornos restringidos. Los investigadores señalan que, incluso con múltiples filtros y controles basados en el análisis sintáctico o listas de prohibición, siempre existen construcciones del lenguaje o comportamientos del intérprete que pueden ser aprovechados para eludir las defensas. De hecho, hace unas semanas otra vulnerabilidad de máxima gravedad en n8n —conocida como Ni8mare y registrada bajo CVE-2026-21858— mostró lo fácil que puede ser para un atacante remoto ganar control total de una instancia, lo que refuerza la urgencia de aplicar correcciones y buenas prácticas.

Ante esta situación, la recomendación inmediata es aplicar las versiones que corrigen las fallas. Para CVE-2026-1470 se han publicado parches en las ramas indicadas por los mantenedores; las versiones que contienen la corrección son 1.123.17, 2.4.5 y 2.5.1. Para CVE-2026-0863, las ediciones corregidas son 1.123.14, 2.3.5 y 2.4.2. Actualizar a estas versiones debe ser la primera acción de mitigación.

Además de actualizar, conviene revisar la arquitectura de despliegue: migrar a ejecuciones separadas entre el servidor de n8n y los runners de tareas, restringir el acceso administrativo a la plataforma, rotar las credenciales y claves almacenadas por n8n y auditar los registros en busca de actividad sospechosa. Si existe la sospecha de que una instancia pudo haber sido comprometida, lo prudente es asumir que secretos y tokens podrían estar expuestos y proceder a su revocación y renovación.

En sectores donde n8n orquesta cadenas que incluyen servicios críticos o datos sensibles, la exposición de una plataforma de automatización es especialmente peligrosa porque permite movimientos laterales automatizados y accesos a recursos que normalmente quedarían fuera del alcance de un intruso. Por eso, además de aplicar los parches, es aconsejable revisar políticas de seguridad, prácticas de segregación de tareas y controles de mínimos privilegios en las integraciones que conecta n8n.

Si gestionas instancias de n8n, consulta las fuentes oficiales para verificar las versiones disponibles y las notas de seguridad. El informe técnico de JFrog está disponible en su blog de investigación (JFrog Research) y los detalles de los identificadores públicos pueden encontrarse en la base de datos de NVD (CVE-2026-1470, CVE-2026-0863, CVE-2026-21858). También es útil revisar la documentación oficial de n8n sobre expresiones y runners para entender mejor las diferencias operativas entre modos y cómo mejorar el aislamiento: Expresiones en n8n y Configuración de task runners.

En definitiva, estas vulnerabilidades subrayan que la complejidad de los lenguajes interpretados y la conveniencia de las plataformas de automatización requieren una gestión de riesgos cuidadosa. Actualizar, aislar procesos y revisar permisos no son solo recomendaciones: en este contexto, son medidas imprescindibles para evitar que una herramienta pensada para facilitar el trabajo se convierta en la puerta de entrada para un ataque a toda la organización.