Qué está pasando con n8n y por qué esto importa
Una vulnerabilidad crítica fue identificada en n8n, una de las plataformas de automatización de workflows más utilizadas por equipos de tecnología, desarrolladores y entusiastas de inteligencia artificial en todo el mundo. La falla, catalogada como CVE-2026-25049, recibió un score CVSS de 9.4 — lo que la coloca en el nivel más elevado de severidad — y permite que un usuario autenticado ejecute comandos arbitrarios directamente en el sistema operativo del servidor donde la plataforma está alojada. En la práctica, estamos hablando de una brecha que puede darle a un atacante el control total de la máquina, comprometiendo no solo los workflows automatizados, sino también todos los datos e integraciones conectadas a esa instancia.
Lo que hace esta situación aún más delicada es que la CVE-2026-25049 no surgió de la nada. En realidad es un bypass de la corrección que fue implementada para una vulnerabilidad anterior, la CVE-2025-68613, que ya había sido tratada en diciembre de 2025 y tenía un CVSS todavía más alto, de 9.9. Esto significa que el primer intento de resolver el problema no fue suficiente. Investigadores de seguridad lograron encontrar caminos para eludir las protecciones añadidas, exponiendo nuevamente los servidores que ejecutan n8n a riesgos serios de ejecución remota de código.
Si utilizas n8n para automatizar procesos, integrar herramientas, conectar APIs u orquestar workflows de inteligencia artificial, este es el tipo de alerta que merece atención inmediata 🚨. No se trata de una falla teórica o difícil de explotar — el vector de ataque exige únicamente que el invasor tenga credenciales válidas en la plataforma, algo que puede obtenerse mediante phishing, credenciales filtradas o incluso por un colaborador interno malintencionado.
Diez investigadores, una falla y un sandbox que no resistió
Uno de los aspectos más reveladores de esta historia es la cantidad de profesionales de seguridad que llegaron a la misma conclusión de forma independiente. Nada menos que 10 investigadores fueron reconocidos por el descubrimiento de la CVE-2026-25049, incluyendo a Fatih Çelik, quien ya había sido responsable de reportar la falla original CVE-2025-68613. Además de él, nombres como Cris Staicu de Endor Labs, Eilon Cohen de Pillar Security y Sandeep Kamble de SecureLayer7 contribuyeron a identificar el problema. Cuando tantas personas encuentran la misma brecha, eso generalmente indica que la superficie de ataque era amplia y relativamente accesible para quien sabe dónde buscar.
En un análisis técnico detallado publicado por Çelik, el investigador explicó que las dos vulnerabilidades pueden considerarse esencialmente la misma falla, ya que la segunda es solo un bypass del fix inicial. El mecanismo de sandbox de expresiones de n8n — que debería aislar el código ejecutado dentro de los workflows — presentaba brechas que permitían al atacante escapar de ese entorno controlado y alcanzar el sistema operativo subyacente.
SecureLayer7 detalló el escenario de ataque de una forma bastante clara: un atacante crea un workflow que utiliza un webhook públicamente accesible, sin autenticación habilitada. Bastaba agregar una única línea de JavaScript utilizando sintaxis de destructuring para que el workflow pasara a ejecutar comandos a nivel del sistema. Una vez expuesto, cualquier persona en internet podría activar ese webhook y ejecutar comandos remotamente en el servidor. Así de simple — y aterradoramente eficiente.
Cómo funciona la ejecución remota de código en esta vulnerabilidad
Para entender el impacto real de la CVE-2026-25049, es importante comprender qué significa ejecución remota de código, o RCE por sus siglas en inglés. Cuando una plataforma presenta este tipo de falla, un atacante logra enviar instrucciones que son interpretadas y ejecutadas por el servidor como si fueran comandos legítimos del sistema operativo. En el caso de n8n, la vulnerabilidad está en la forma en que la plataforma evalúa expresiones dentro de los parámetros de workflow. Un usuario autenticado con permiso para crear o modificar workflows puede manipular expresiones elaboradas en esos parámetros para disparar la ejecución no intencional de comandos en el host que ejecuta n8n.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
La explicación técnica ofrecida por Cris Staicu, de Endor Labs, revela un matiz fascinante. El problema se origina en un desajuste entre el sistema de tipos de TypeScript en tiempo de compilación y el comportamiento real de JavaScript en tiempo de ejecución. Mientras TypeScript impone que determinada propiedad debería ser un string durante la compilación, esa garantía se limita a los valores presentes en el código en ese momento. TypeScript simplemente no puede aplicar esas verificaciones de tipo en valores producidos por atacantes en runtime. Cuando los invasores crean expresiones maliciosas en tiempo de ejecución, logran pasar valores que no son strings — como objetos, arrays o symbols — que eluden completamente la verificación de sanitización.
El problema es especialmente grave porque n8n frecuentemente se despliega con permisos elevados en el servidor, justamente por necesitar acceder a diferentes servicios, bases de datos y APIs externas para realizar las automatizaciones. Esto significa que, al explotar esta vulnerabilidad, el atacante hereda esos permisos y puede leer archivos sensibles, instalar backdoors, exfiltrar datos de integraciones conectadas como bases de datos, plataformas de CRM, servicios de correo electrónico e incluso moverse lateralmente por la red interna de la organización.
El peligro amplificado por los webhooks
La gravedad de la CVE-2026-25049 aumenta considerablemente cuando se combina con la funcionalidad de webhooks de n8n. Tanto SecureLayer7 como Pillar Security destacaron este punto con énfasis. El escenario funciona así:
- El atacante crea un workflow que utiliza un webhook público, sin ninguna capa de autenticación
- Dentro de ese workflow, un payload de ejecución remota de código se agrega a un nodo específico
- Cuando el workflow se activa, el webhook se vuelve accesible públicamente desde internet
- Cualquier persona que acceda a la URL del webhook activa la ejecución de los comandos maliciosos en el servidor
Eilon Cohen, de Pillar Security, resumió la situación de forma bastante directa: el ataque no requiere nada especial — si puedes crear un workflow, puedes ser dueño del servidor. El informe de Pillar detalló que la explotación exitosa permite robar claves de API, credenciales de proveedores de nube, contraseñas de bases de datos, tokens OAuth y acceder al sistema de archivos y sistemas internos. A partir de ahí, el atacante puede pivotar hacia cuentas de nube conectadas e hasta secuestrar workflows de inteligencia artificial.
Considerando que muchas organizaciones utilizan n8n como pieza central de sus automatizaciones, incluso para orquestar flujos que involucran modelos de lenguaje (LLMs) y agentes de IA, el compromiso de la plataforma puede tener consecuencias que van mucho más allá del servidor en sí. Estamos hablando de un potencial efecto dominó que puede afectar toda la infraestructura digital de una empresa.
Versiones afectadas y cómo actualizar
El equipo de desarrollo de n8n publicó correcciones para la CVE-2026-25049 en las siguientes versiones:
- Versiones anteriores a 1.123.17 son vulnerables — la corrección está en la versión 1.123.17
- Versiones anteriores a 2.5.2 son vulnerables — la corrección está en la versión 2.5.2
El paso más urgente para cualquier persona u organización que mantenga una instancia de n8n en producción es actualizar inmediatamente a la versión más reciente de la plataforma. Postergar esta actualización es asumir un riesgo innecesario, especialmente considerando que los detalles técnicos de la vulnerabilidad ya están circulando en comunidades de seguridad y es cuestión de tiempo hasta que se desarrollen y difundan herramientas automatizadas de explotación.
Si la actualización inmediata no es viable, los mantenedores de n8n recomiendan las siguientes medidas de mitigación:
- Restringir los permisos de creación y edición de workflows solo a usuarios totalmente confiables
- Desplegar n8n en un entorno reforzado, con privilegios restringidos de sistema operativo y acceso de red limitado
No es solo la CVE-2026-25049 — otras 11 fallas fueron corregidas
Como si la CVE-2026-25049 no fuera suficiente, n8n también divulgó alertas de seguridad para otras 11 vulnerabilidades, cinco de ellas clasificadas como críticas. La lista completa muestra que la plataforma pasó por una auditoría de seguridad bastante intensa, revelando problemas en diferentes componentes:
- CVE-2026-21893 (CVSS 9.4) — Inyección de comandos que permite a usuarios autenticados con permisos administrativos ejecutar comandos arbitrarios en el host de n8n, bajo condiciones específicas. Corregida en la versión 1.120.3.
- CVE-2026-25051 (CVSS 8.5) — Vulnerabilidad de cross-site scripting (XSS) en el tratamiento de respuestas de webhook y endpoints HTTP relacionados, pudiendo llevar a secuestro de sesión y toma de cuenta. Corregida en la versión 1.123.2.
- CVE-2026-25052 (CVSS 9.4) — Vulnerabilidad de Time-of-check Time-of-use (TOCTOU) en los controles de acceso a archivos, permitiendo lectura de archivos sensibles del host y potencial toma completa de cuenta. Corregida en las versiones 2.5.0 y 1.123.18.
- CVE-2026-25053 (CVSS 9.4) — Inyección de comando en el nodo Git, permitiendo ejecución de comandos arbitrarios o lectura de archivos en el host. Corregida en las versiones 2.5.0 y 1.123.10.
- CVE-2026-25054 (CVSS 8.5) — XSS almacenado en componente de renderización de markdown, incluyendo sticky notes de workflow. Corregida en las versiones 2.2.1 y 1.123.9.
- CVE-2026-25055 (CVSS 7.1) — Travesía de directorios (path traversal) que permite escritura de archivos en ubicaciones no previstas mediante el nodo SSH. Corregida en las versiones 2.4.0 y 1.123.12.
- CVE-2026-25056 (CVSS 9.4) — Escritura arbitraria de archivos en el sistema de archivos del servidor n8n mediante el modo SQL Query del nodo Merge, pudiendo llevar potencialmente a ejecución remota de código. Corregida en las versiones 2.4.0 y 1.118.0.
- CVE-2026-25115 (CVSS 9.4) — Escape del sandbox Python en el nodo de código Python, permitiendo ejecución de código fuera del límite de seguridad previsto cuando Task Runners y Python están habilitados. Corregida en la versión 2.4.8.
- CVE-2026-25631 (CVSS 5.3) — Validación inadecuada de dominio de credenciales en el nodo HTTP Request, permitiendo envío de solicitudes con credenciales a dominios no previstos. Corregida en la versión 1.121.0.
- CVE-2025-61917 (CVSS 7.7) — Asignación insegura de buffer que puede exponer información sensible cuando Task Runners están habilitados. Corregida en la versión 1.114.3.
- CVE-2025-62726 (CVSS 8.8) — Ejecución remota de código en el componente Git Node cuando se clona un repositorio remoto que contiene un hook de pre-commit. Corregida en la versión 1.113.0.
Esta extensa lista refuerza que n8n tenía una superficie de ataque considerable. La buena noticia es que todas estas fallas ya cuentan con parches disponibles, pero el mensaje es claro: mantener la plataforma actualizada no es opcional.
Qué hacer ahora para proteger tu instancia
Además de la actualización en sí, existen buenas prácticas que ayudan a reducir la superficie de ataque y que deberían adoptarse independientemente de esta vulnerabilidad específica. Limitar el acceso a la interfaz de n8n solo a redes internas o VPNs confiables, por ejemplo, reduce drásticamente la posibilidad de que un atacante externo explote la falla. Implementar autenticación multifactor para todos los usuarios de la plataforma agrega una capa extra de protección que dificulta el uso de credenciales comprometidas.
Revisar periódicamente los usuarios registrados y eliminar cuentas que ya no son necesarias también es una medida sencilla que marca la diferencia. Para quienes ejecutan n8n en contenedores Docker, garantizar que el contenedor opere con el mínimo de privilegios posible y con un sistema de archivos de solo lectura donde sea viable puede limitar el impacto incluso en caso de ejecución remota exitosa.
Otro punto fundamental es revisar los logs de acceso de la plataforma para identificar cualquier actividad sospechosa que pueda indicar un intento de explotación anterior a la aplicación del parche. Verifica especialmente workflows que utilicen webhooks públicos sin autenticación, ya que estos son los vectores más directos para la explotación de la CVE-2026-25049.
Herramientas que usamos a diario
Endor Labs cerró su análisis con una reflexión técnica que aplica para cualquier proyecto de software: esta vulnerabilidad demuestra por qué múltiples capas de validación son cruciales. Aunque una capa, como los tipos de TypeScript, parezca robusta, verificaciones adicionales en runtime son necesarias al procesar entradas no confiables. El mensaje es prestar especial atención a las funciones de sanitización durante las revisiones de código, buscando suposiciones sobre tipos de entrada que no se refuerzan en tiempo de ejecución.
Lecciones para quienes trabajan con automatización e IA
Este episodio también sirve como un recordatorio importante sobre la responsabilidad de mantener plataformas self-hosted actualizadas y monitoreadas. El investigador Amit Genkin, de Upwind, puso la cuestión en perspectiva al afirmar que la flexibilidad y el poder de n8n son exactamente lo que hacen que estos problemas sean de alto impacto. Cuando los motores de automatización tienen permiso para influir directamente en la ejecución y el acceso a archivos, pequeños errores se transforman rápidamente en un compromiso total del entorno.
n8n es una herramienta poderosa y extremadamente versátil, pero justamente por manejar integraciones sensibles y tener acceso a múltiples servicios, cualquier brecha de seguridad en ella puede tener un efecto cascada significativo. Seguir los canales oficiales de comunicación del proyecto, suscribirse a alertas de seguridad y participar en la comunidad son formas de mantenerse informado sobre nuevas amenazas.
Para quienes están construyendo workflows que involucran modelos de lenguaje, agentes autónomos o cualquier tipo de sistema de IA, este caso es un recordatorio de que la seguridad de la infraestructura de orquestación es tan importante como la seguridad de los propios modelos. De nada sirve invertir en guardrails para tus LLMs si la plataforma que los conecta y gestiona es vulnerable a una toma completa por parte de un atacante.
La CVE-2026-25049 es seria, pero con las medidas correctas aplicadas rápidamente, es posible seguir aprovechando todo lo que n8n ofrece sin poner tu infraestructura en riesgo 🔐. Actualiza tus instancias, revisa tus configuraciones de seguridad y mantén tus workflows protegidos.
