n8n es una plataforma de automatización muy potente que permite ejecutar comandos en servidores, conectarse por SSH, hacer Git pulls, procesar pagos, etc. Justamente por eso, cuando aparece una vulnerabilidad, el impacto potencial puede ser alto: ejecución de código en el servidor, robo de cuentas o incluso comprometer otros sistemas conectados.
Los avisos de seguridad publicados recientemente describen un conjunto de fallos graves descubiertos entre enero y febrero de 2026. Afectan a distintos componentes, por ejemplo: nodos Git, SSH, Merge, Stripe Trigger, motor de expresiones y la interfaz web y, en varios casos, permiten la ejecución remota de código (RCE) o secuestro de sesiones de usuario.
A continuación se explica, en lenguaje sencillo, en qué consiste cada vulnerabilidad, qué riesgo implica y qué versiones corrigen el problema. Al final se incluye una recomendación clara de versión a la que se debe actualizar.
1. Vulnerabilidades que permiten ejecutar código en el servidor de n8n
1.1 Escape de expresión que conduce a RCE
¿Qué es?
n8n permite usar expresiones (por ejemplo {{$json["campo"]}}) en muchos parámetros de los nodos. El fallo descubierto permite a un usuario autenticado, con permisos para crear o modificar workflows, fabricar expresiones especiales que “rompen” el entorno de evaluación y acaban ejecutando comandos del sistema operativo en el servidor donde corre n8n.
Riesgo práctico:
El atacante no necesita ser administrador, solo poder editar workflows.
Una vez explotada, la vulnerabilidad permite:
Leer y modificar archivos en el host.
Acceder a bases de datos y credenciales almacenadas en n8n.
Utilizar el servidor como punto de entrada para moverse por la red interna.
Por eso se considera una vulnerabilidad crítica de ejecución remota de código (RCE).
Versiones afectadas y parche:
Afecta a todas las versiones < 1.123.17 y < 2.5.2.
Se corrige a partir de 1.123.17 y 2.5.2.
1.2 Inyección de comandos del sistema operativo en el nodo Git
¿Qué es?
El nodo Git de n8n permite, por ejemplo, clonar repositorios o sincronizar código. En las versiones vulnerables, ciertos parámetros controlados por el usuario se acababan usando de forma insegura al construir comandos del sistema (git ...). Esto abre la puerta a que un usuario con permiso para crear o modificar workflows inyecte comandos adicionales en el sistema operativo.
Riesgo práctico:
Requiere un usuario autenticado con permiso de crear o editar workflows, pero no necesariamente administrador.
El atacante puede:
Ejecutar comandos arbitrarios en el servidor n8n.
Leer archivos sensibles.
Escalar el ataque a otros sistemas conectados.
Por su impacto sobre confidencialidad, integridad y disponibilidad, se clasifica como crítica.
Versiones afectadas y parche:
Afecta a:
Toda la rama 1.x anterior a 1.123.10.
Las versiones 2.x desde 2.0.0 hasta antes de 2.5.0.
Se corrige en 1.123.10 y 2.5.0.
1.3 Inyección de comandos en la instalación de paquetes comunitarios
¿Qué es?
n8n permite instalar “community packages” directamente desde la interfaz. En versiones afectadas, el parámetro version de estos paquetes se construía de forma insegura dentro de un comando de shell. Un administrador malicioso podía introducir contenido especialmente diseñado en ese campo para inyectar comandos.
Riesgo práctico:
Solo es explotable por administradores (o cuentas equivalentes).
A nivel de modelo de amenazas, un admin ya puede subir código propio, por lo que el fabricante considera que no amplía mucho el riesgo más allá de las capacidades habituales de un administrador.
Aun así, es un defecto importante de validación de entradas y se ha corregido.
Versiones afectadas y parche:
Afecta desde 0.187.0 hasta antes de 1.120.3.
Se corrige en 1.120.3 y posteriores de la rama 1.x.
En la práctica, para tener todas las demás correcciones críticas, si sigues en 1.x deberías ir más allá de 1.120.3 igualmente.
1.4 Escritura de archivo arbitrario en el nodo Merge
¿Qué es?
El nodo Merge, en su modo “SQL Query”, permitía a un usuario autenticado escribir archivos arbitrarios en el sistema de archivos del servidor n8n. Combinado con rutas especiales, esto puede usarse para colocar archivos ejecutables o scripts en ubicaciones sensibles, lo que desemboca de nuevo en RCE.
Riesgo práctico:
Explota un usuario autenticado con permiso para crear o modificar workflows.
Impacto:
Posible toma de control total del servidor n8n.
Modificación maliciosa de código, configuración o binarios.
Puerta de entrada a otros sistemas de la red.
Versiones afectadas y parche:
Afecta a:
Todas las versiones < 1.118.0.
Versiones 2.0.0 hasta antes de 2.4.0.
Se corrige en 1.118.0 y 2.4.0.
2. Compromiso de sistemas remotos vía SSH
¿Qué es?
Cuando un workflow de n8n acepta archivos subidos (por ejemplo, vía un webhook) y luego los envía a otra máquina usando el nodo SSH, las versiones vulnerables no validaban correctamente ciertos metadatos del archivo (sobre todo la ruta). Esto permite a un atacante escribir archivos en ubicaciones arbitrarias en el sistema remoto, potencialmente en rutas que luego se ejecutan (por ejemplo, un script en un directorio de arranque).
Riesgo práctico:
El atacante no tiene por qué estar autenticado en n8n:
Solo necesita conocer un endpoint de webhook que acepte subida de archivos sin autenticación y que luego use el nodo SSH para subirlos.
Impacto en el sistema remoto:
Escritura de archivos maliciosos.
Posible ejecución de código (RCE) si se consigue colocar el archivo en una ruta ejecutable o cargada por la aplicación.
Versiones afectadas y parche:
Afecta a:
Versiones < 1.123.12.
Versiones 2.0.0 hasta antes de 2.4.0.
Se corrige en 1.123.12 y 2.4.0.
3. Vulnerabilidades en la capa web: XSS y bypass de autenticación
3.1 XSS almacenado en markdown de la UI
¿Qué es?
Varias partes de la interfaz de n8n (por ejemplo, las “sticky notes” de los workflows) permiten contenido en markdown. En las versiones afectadas, el motor de renderizado no limpiaba bien el HTML generado, de modo que un usuario con permisos para editar workflows podía inyectar JavaScript que se ejecuta en el navegador de otros usuarios que abran ese workflow.
Riesgo práctico:
Atacante: usuario autenticado con permiso para crear/modificar workflows.
Víctima: otro usuario que abra o interactúe con ese workflow.
El JavaScript malicioso se ejecuta con los permisos del navegador hacia la instancia de n8n (mismo origen). Esto permite:
Robar cookies o tokens de sesión.
Ejecutar acciones en nombre de la víctima (secuestro de cuenta).
Exfiltrar datos que el usuario vea en la UI.
Por eso se cataloga como XSS almacenado de alta gravedad.
Versiones afectadas y parche:
Afecta a:
Versiones < 1.123.9.
Versiones 2.0.0 hasta antes de 2.2.1.
Se corrige en 1.123.9 y 2.2.1.
3.2 Stripe Trigger sin verificación de firma
¿Qué es?
El nodo Stripe Trigger registra un webhook en Stripe y almacena un secreto de firma para validar los eventos entrantes. El problema es que, en las versiones vulnerables, n8n no comprobaba esa firma cuando llegaba un evento. Bastaba con conocer la URL del webhook para enviar un POST con un tipo de evento válido y desencadenar el workflow como si fuera Stripe.
Riesgo práctico:
No se requiere autenticación en n8n: quien conozca la URL del webhook puede abusar del fallo.
El riesgo se mitiga parcialmente porque:
La URL contiene un UUID de alta entropía difícil de adivinar.
Pero cualquier usuario autenticado que vea el workflow puede ver la URL, y puede filtrarla.
Impacto:
Generar eventos de pago o suscripción falsos.
Desencadenar acciones automatizadas (por ejemplo, dar acceso a un servicio, enviar productos, actualizar CRM) sin que Stripe haya enviado nada.
Versiones afectadas y parche:
Afecta a todas las versiones desde 0.150.0 hasta antes de 2.2.2.
Se corrige en 2.2.2 y posteriores.
No se menciona un parche específico en la rama 1.x; la recomendación oficial es actualizar a 2.2.2 o superior.
4. ¿Qué significan estos fallos para una instalación típica de n8n?
Resumiendo los vectores de ataque:
Ataques desde usuarios internos o integradores con cuenta en n8n:
Pueden explotar:
La vulnerabilidad de expresiones.
El nodo Git.
El Merge node.
El XSS en markdown.
Todos ellos permiten escalar desde “puedo editar workflows” a:
Tomar control del servidor de n8n o de la sesión de otros usuarios.
Acceder a credenciales almacenadas y datos procesados.
Ataques desde Internet sin autenticación:
Stripe Trigger, si alguien conoce la URL del webhook.
SSH node, si hay un endpoint de subida de archivos sin autenticación que luego use SSH para transferir archivos.
Ataques por parte de administradores:
La inyección de comandos en community packages requiere ser administrador y, por tanto, no amplía tanto el modelo de amenazas, pero sí revela una superficie de ataque dentro del propio panel de administración.
En conjunto, estos fallos amplían de forma notable la capacidad de un usuario con permisos limitados para comprometer todo el entorno y, en algunos casos, permiten ataques totalmente externos si ciertas buenas prácticas (como proteger webhooks) no se siguen.
5. Versiones mínimas que corrigen cada fallo
Rama 2.x
Para cada aviso, la primera versión 2.x que incluye corrección es:
Stripe Trigger, auth bypass: 2.2.2.
XSS markdown: 2.2.1.
SSH node, escritura en sistemas remotos: 2.4.0.
Merge node, escritura en servidor n8n: 2.4.0.
Git node, comando del sistema: 2.5.0.
Expression escape RCE: 2.5.2.
Por tanto, dentro de 2.x, la versión mínima que corrige todas las vulnerabilidades de tu lista es 2.5.2.
Rama 1.x
Aunque ya está en fase de fin de vida, la rama 1.x también recibió parches:
community packages: 1.120.3.
Git node: 1.123.10.
XSS: 1.123.9.
SSH node: 1.123.12.
Merge node: 1.118.0.
Expression escape: 1.123.17.
Sin embargo, para el problema de Stripe Trigger se recomienda solo la versión 2.2.2 como versión corregida, con rango afectado >=0.150.0, <2.2.2. Esto implica que todas las versiones 1.x quedan dentro del rango vulnerable y que la mitigación completa pasa por migrar a 2.x.
Además, hay avisos externos que señalan que la rama 1.x entra en fin de soporte (EOL) alrededor de marzo de 2026.
6. ¿Qué versión concreta conviene instalar hoy?
6.1 Versión recomendada
Teniendo en cuenta:
Las versiones mínimas corregidas por cada vulnerabilidad.
El hecho de que la vulnerabilidad de expresiones solo queda completamente resuelta a partir de 2.5.2.
Recomendaciones de terceros que identifican 2.5.2 como la versión mínima segura tras estas vulnerabilidades.
Que ya existen versiones posteriores (2.6.0, 2.7.0) que se basan en ese código y añaden mejoras adicionales.
La recomendación práctica es:
Mínimo absoluto para producción:
n8n 2.5.2 o superior.Versión recomendada a día de hoy (más reciente estable conocida):
Una versión de la rama 2.7.x, ya que los registros de cambios públicos muestran que 2.7.0 se publicó después de integrar todas las correcciones de seguridad descritas y añade mejoras de estabilidad y rendimiento.
En otras palabras:
Para estar protegido frente a todas las vulnerabilidades, se debe ejecutar n8n 2.5.2 o una versión posterior. Si se quiere estar alineado con el estado más actual del proyecto, se recomienda actualizar directamente a la versión estable más reciente disponible de la rama 2.x (por ejemplo, 2.7.0).
6.2 Si todavía estás en n8n 1.x
Desde el punto de vista de seguridad:
No es posible eliminar completamente el riesgo del fallo de Stripe Trigger quedándose en 1.x.
Aunque algunos fallos críticos se parchean en versiones como 1.118.0, 1.120.3, 1.123.12 y 1.123.17, la combinación de:
Nuevas vulnerabilidades recientes, y
El fin de vida programado de 1.x hace que seguir en esta rama sea una mala práctica de seguridad.
La recomendación es planificar una migración ordenada a 2.x, idealmente a la versión estable más reciente que ofrezca el proveedor (≥ 2.5.2).
7. Medidas adicionales de mitigación
Además de actualizar la versión de n8n, conviene aplicar buenas prácticas que reducen el impacto de vulnerabilidades futuras:
Restringir quién puede crear o modificar workflows
Conceder permisos de edición solo a usuarios de confianza.
Separar claramente roles de lectura, ejecución y edición.
Limitar el uso de nodos de alto riesgo
Evaluar si realmente se necesitan los nodos:
Execute Command.
SSH.
Git.
Merge en modo SQL Query.
Deshabilitarlos globalmente si no son necesarios, siguiendo la documentación oficial de “blocking nodes”.
Proteger todos los webhooks y endpoints de subida de archivos
Activar autenticación en webhooks especialmente cuando:
Aceptan archivos y los envían a otros sistemas (caso SSH node).
Desencadenan operaciones sensibles (altas de usuarios, pagos, etc.).
Revisar workflows existentes
Buscar:
Uso inusual de expresiones complejas.
Workflows que usen Git, SSH, Merge (SQL) u otros nodos con acceso al sistema.
Notas o campos markdown que podrían contener XSS.
Endurecer el entorno donde corre n8n
Ejecutar n8n en contenedores con permisos limitados.
Aislar la base de datos y otros servicios críticos.
Aplicar segmentación de red para que un compromiso de n8n no signifique acceso total a toda la infraestructura.
Conclusión
Las vulnerabilidades recientes abarcan desde problemas en la interfaz (XSS) y en la integración con Stripe (bypass de autenticación), hasta fallos críticos que permiten ejecutar comandos arbitrarios en el servidor de n8n o en máquinas remotas a través de nodos como Git, SSH, Merge o del motor de expresiones.
Por ello, no basta con aplicar un único parche: se requiere estar, como mínimo, en n8n 2.5.2, que es la primera versión de la rama 2.x que incorpora todas las correcciones de seguridad asociadas a estos avisos. Dado que ya existen versiones posteriores (como 2.7.0) que se construyen sobre esas correcciones, la recomendación práctica es actualizar directamente a la versión estable más reciente disponible en la rama 2.x y, en paralelo, reforzar permisos, nodos habilitados y autenticación de webhooks.
Comentarios
Publicar un comentario