CVE-2026-27577 en n8n: Cuando el parche mismo es evadido

Quien aloja n8n por su cuenta conoce la rutina: leer la notificación de seguridad, actualizar la versión, marcar como hecho. Con CVE-2026-27577 esa rutina no fue suficiente. La vulnerabilidad fue parcheada el 25 de febrero de 2026, y en julio de 2026 investigadores de seguridad evadieron exactamente ese parche nuevamente.

Esto no es un resbalón, sino el cuarto intento documentado sobre el mismo componente en ocho meses. Para instancias alojadas por usted mismo, esto cambia la pregunta: no si ha instalado una actualización específica, sino si tiene un proceso que detecte los intentos posteriores sobre el mismo punto. Hemos descrito la situación general en vulnerabilidades de seguridad de n8n 2026. Este artículo profundiza en la evasión misma.

¿Qué es exactamente CVE-2026-27577?

CVE-2026-27577 es una vulnerabilidad crítica en la evaluación de expresiones de n8n, a través de la cual un usuario autenticado con derecho a crear o modificar flujos de trabajo puede ejecutar comandos del sistema en el host mediante expresiones preparadas en parámetros del flujo.

El NVD cataloga la vulnerabilidad con CVSS 3.1 de 9,9 (crítica) y la clase de vulnerabilidad CWE-94, Inyección de código. El Aviso de seguridad de GitHub GHSA-vpcf-gvg4-6qwr la valora adicionalmente según CVSS 4.0 con 9,4. Afecta a todas las versiones anteriores a 1.123.22, la serie 2.x desde 2.0.0 anterior a 2.9.3, así como 2.10.0. Está parcheada en 1.123.22, 2.9.3 y 2.10.1, los tres publicados en npm el 25 de febrero de 2026.

Importante para clasificar: n8n describe CVE-2026-27577 en su aviso propio explícitamente como complemento a CVE-2025-68613, la vulnerabilidad original en la evaluación de expresiones de diciembre de 2025. Entre ambas estaba ya CVE-2026-25049 del 4 de febrero de 2026, también CVSS 3.1 de 9,9, también una forma de evadir el mismo mecanismo de protección.

¿Por qué fue evadido el parche a CVE-2026-27577 en julio de 2026?

La corrección a CVE-2026-27577 cerró el vector de ataque específicamente reportado, pero no la vulnerabilidad subyacente en el reescritor de expresiones. La empresa de seguridad Security Joes demostró en julio de 2026 que el mismo acceso al tiempo de ejecución de Node.js puede alcanzarse a través de una construcción lingüística diferente.

Technisch beschreibt Security Joes zwei Blindstellen, die einzeln harmlos sind und erst zusammen greifen: Die Umschreibung freier Bezeichner überspringt Pfeilfunktionen, sodass ein Ausdruck der Form „Pfeilfunktion, die das Prozess-Objekt zurückgibt“ am Schutz vorbeiläuft, und die Sperrliste für gefährliche Eigenschaften prüft nur statisch notierte Namen, greift also nicht, wenn derselbe Name als Zeichenkette übergeben wird. Verifiziert wurde das laut Veröffentlichung auf n8n 2.30.4, also auf einem Stand nach der Patch-Linie zu CVE-2026-27577 (Quelle: Security Joes, „Breaking the Sandbox Again“, 27. Juli 2026).

El proceso habla en favor del fabricante: Security Joes reportó el hallazgo el 15 de julio de 2026 a través del programa de Divulgación de Vulnerabilidades de n8n, el 22 de julio de 2026 la corrección estaba implementada y el Aviso GHSA-gv7g-jm28-cr3m fue publicado, valorado con CVSS 4.0 de 8,7. Este vector está parcheado en 2.31.5 y 2.32.1. El mismo día n8n publicó con CVE-2026-65591 (CVSS 4.0 de 8,9) una segunda evasión del mismo tipo en el evaluador de expresiones más antiguo, parcheado en 1.123.64, 2.29.8 y 2.30.1.

¿Qué versión de n8n es segura ahora?

Una versión está segura frente a todas las evasiones mencionadas aquí solo a partir de 1.123.67, 2.31.5 o 2.32.1, porque los parches de julio están después de la línea de parches de CVE-2026-27577. Si actualizó en febrero de 2026 a 1.123.22 o 2.10.1 y no ha hecho nada desde entonces, está vulnerable.

• Vulnerabilidad de expresiones CVE-2025-68613 (diciembre de 2025): corregida en 1.120.4, 1.121.1 y 1.122.0.
• Evasión CVE-2026-25049 (4 de febrero de 2026): corregida en 1.123.17 y 2.5.2.
• Evasión CVE-2026-27577 (25 de febrero de 2026): corregida en 1.123.22, 2.9.3 y 2.10.1.
• Evasión CVE-2026-65591 (22 de julio de 2026): corregida en 1.123.64, 2.29.8 y 2.30.1.
• Evasión mediante funciones de flecha, GHSA-gv7g-jm28-cr3m (22 de julio de 2026): corregida en 2.31.5 y 2.32.1.

Al cierre de la edición de este artículo, 2.32.7 del 31 de julio de 2026 es la versión estable actual en npm. Encuentra el número de versión de su instancia en la configuración de la interfaz.

¿Quién puede editar flujos de trabajo en su entorno?

Todas las vulnerabilidades de esta serie requieren una cuenta autenticada con derecho a crear o modificar flujos de trabajo. Esto hace que la asignación de permisos en n8n no sea una configuración de comodidad, sino un límite de seguridad: quien pueda editar flujos de trabajo está, frente a una evasión abierta, prácticamente al mismo nivel que un usuario con acceso de shell al servidor.

En muchas instalaciones que asumimos, simplemente todos los involucrados tienen permisos de edición, porque fue lo más rápido durante la configuración y nadie lo revirtió después. En instancias gestionadas, por lo tanto, verificamos no solo la versión sino también quién tiene permisos de edición y si la interfaz debe ser accesible desde Internet abierto. Ambos forman parte en nosotros del funcionamiento continuo de una instancia n8n, no una acción especial después de cada titular.

¿Qué deben hacer ahora los que alojan sus propias instancias?

La única protección completa es la actualización, así lo dicen los avisos de n8n mismos. Las medidas transitorias mencionadas en ellos mitigan la situación pero explícitamente no la resuelven.

• Verificar versión y actualizar: al menos a 1.123.67, 2.31.5 o 2.32.1, preferiblemente a la versión estable actual.
• Reducir permisos de edición: solo quienes realmente lo necesiten para su trabajo pueden crear y modificar flujos. Esta es la medida transitoria recomendada por n8n mismo.
• Actualizar credenciales si permaneció durante un tiempo en una versión vulnerable: Security Joes recomienda que en este caso se considere la clave de cifrado de la instancia como comprometida y se cambien las credenciales almacenadas, porque un ataque exitoso accede exactamente a eso.
• No exponer la interfaz directamente a Internet: Acceso a través de VPN o un proxy inverso protegido, ver las pautas de endurecimiento en la documentación de n8n.
• Seguir notificaciones de forma permanente: suscribirse a los Avisos de Seguridad de GitHub de n8n y planificar una ventana de actualización fija, en lugar de reaccionar por demanda.

Esta serie de CVE muestra por qué el consejo trivial es el decisivo: entre el parche del 25 de febrero y el del 22 de julio pasaron casi cinco meses, durante los cuales una instancia actualizada correctamente seguía siendo vulnerable en cuanto alguien encontraba el siguiente camino. n8n proporciona pautas extensas de endurecimiento en docs.n8n.io.

Preguntas frecuentes

¿Está afectada n8n Cloud por CVE-2026-27577?

n8n actualiza su propio entorno de nube, la gestión de parches está en manos del proveedor. El peligro práctico de esta serie de CVE afecta principalmente a instancias alojadas por usted mismo que no se actualizan a tiempo. El problema de permisos persiste en ambos modelos operativos, porque una cuenta con derechos de edición de flujos es el requisito previo para el ataque.

¿Es suficiente actualizar a 1.123.22 o 2.10.1?

No, solo cierra CVE-2026-27577 mismo. Las evasiones del mismo mecanismo de protección publicadas en julio de 2026 solo están corregidas a partir de 1.123.67, 2.31.5 o respectivamente 2.32.1, la evasión en el evaluador más antiguo a partir de 1.123.64, 2.29.8 y 2.30.1.

¿Cómo puedo saber si mi instancia fue comprometida?

No existe un indicador cierto de identificación desde la distancia. Tiene sentido revisar el historial de ejecución para flujos con expresiones inusuales en parámetros de nodos y verificar las conexiones salientes del servidor. En caso de sospecha, se aplica el principio de la publicación de Security Joes: tratar las credenciales como comprometidas y cambiarlas.

¿Por qué el mismo componente es afectado cuatro veces?

Porque la evaluación de expresiones de n8n debe permitir que los usuarios ejecuten JavaScript y simultáneamente aislarlo del tiempo de ejecución del servidor. Cada parche inicialmente cierra el camino reportado. Security Joes formula exactamente esto como patrón: la corrección a CVE-2026-27577 fue correcta para el caso reportado, pero no se hizo la pregunta más general sobre otros construcciones lingüísticas que podrían ser omitidas.

¿Ayuda NordFlux a asegurar instancias existentes de n8n?

Sí. Verificamos el estado de versión, asignación de permisos y protección de acceso en instalaciones existentes y asumimos la gestión de actualizaciones continua si lo desea. Un resumen de nuestro trabajo con n8n lo encontrará en la página de servicios de n8n.