Alerta de seguridad: n8n corrige vulnerabilidad que permitía a editores de workflows ejecutar comandos en el servidor

n8n ha liberado parches para una vulnerabilidad de escape del sandbox de expresiones que permite a un editor autenticado de workflows ejecutar comandos del sistema operativo en el servidor que aloja la plataforma de automatización. La falla afecta a versiones anteriores a 2.31.5 y a la serie 2.32.0 hasta 2.32.0 inclusive; las correcciones están en 2.31.5 y 2.32.1, y el problema está registrado en GitHub como GHSA-gv7g-jm28-cr3m con una puntuación CVSS 4.0 de 8.7. El proveedor publicó los lanzamientos parcheados el 22 de julio tras recibir el reporte de los investigadores el 15 de julio; no había CVE asignado a 27 de julio de 2026.

Desde el punto de vista técnico, el vector aprovecha dos debilidades combinadas en el reescritor del árbol de sintaxis abstracta (AST) que n8n usa para trasladar identificadores de JavaScript a un contexto controlado por la plataforma. La primera es una omisión en el manejo de ArrowFunctionExpression, que permitía que una forma concisa de una arrow function —por ejemplo, () => process— resolviera el identificador contra el runtime de Node.js en vez del contexto seguro. La segunda es una comprobación de propiedades que sólo inspeccionaba nombres estáticos en expresiones miembro, obviando que funciones como Reflect.get pueden recibir la propiedad solicitada como argumento y ser usadas para recuperar módulos integrados y ejecutar child_process.

La combinación de esos dos fallos permitió a los investigadores recuperar process.getBuiltinModule, cargar child_process y ejecutar comandos con los privilegios del proceso n8n. La explotación requiere únicamente una cuenta válida con permiso para crear o modificar workflows; no depende de la interacción de otro usuario. Un ataque exitoso puede exponer la variable N8N_ENCRYPTION_KEY y con ello descifrar credenciales almacenadas en n8n, así como abrir caminos hacia bases de datos, servicios internos y endpoints en la nube accesibles desde el host.

Más allá de la técnica, este incidente subraya una lección recurrente para plataformas low-code/no-code y automations: quienes pueden editar flujos son objetivos de alto valor. Permitir que usuarios con acceso a la construcción de workflows dispongan de entrada libre a scripts embebidos o expresiones aumenta la superficie de ataque. La seguridad operativa exige combinar parches rápidos con controles de acceso fuertes y políticas de secretos y privilegios.

Como medidas inmediatas, la recomendación clave es actualizar a las versiones corregidas (2.31.5 o 2.32.1) en todas las instancias afectadas en vez de confiar sólo en las mitigaciones provisionales que n8n describe en su aviso. Estas mitigaciones —restringir el acceso a la edición de workflows a usuarios completamente de confianza— son útiles como medida temporal, pero el vendor las califica como incompletas y de corto plazo.

Tras la actualización conviene realizar una revisión de alcance: inspeccionar workflows creados o modificados recientemente en busca de arrow functions concisas o JavaScript ofuscado, auditar los logs del host para procesos hijos no esperados (bash, sh, PowerShell, curl, wget u otros invocados por Node.js/n8n) y buscar actividad de descifrado o accesos a recursos sensibles. Si se detecta ejecución sospechosa, debe rotarse N8N_ENCRYPTION_KEY, rotarse credenciales almacenadas y auditar las cuentas y accesos implicados, ya que el riesgo de pivot hacia servicios internos o APIs en la nube es real.

En términos de mitigación a medio y largo plazo, las organizaciones deberían aplicar control de acceso basado en roles y autenticación fuerte (MFA/SSO) para separar claramente a los constructores de workflows de las cuentas que sólo consumen automatizaciones. También es recomendable minimizar los privilegios que las credenciales almacenadas en n8n tienen en los sistemas conectados, emplear credenciales de alcance limitado o temporales cuando sea posible, y segmentar la red para reducir el alcance de un host comprometido.

El incidente también pone en evidencia la importancia de las pruebas de seguridad de componentes que manipulan código o sintaxis (parsers, reescritores AST, sandboxes). Según los investigadores, ninguna de las dos condiciones explotadas estaba cubierta por pruebas automatizadas, lo que facilitó la regresión tras un arreglo previo en febrero (CVE-2026-27577) destinado a cerrar un escape similar. Las organizaciones proveedoras de estas plataformas deben mejorar los tests de seguridad y las revisiones de código para casos límite.

Si utiliza n8n Cloud, verifique con el fabricante si su entorno hospeda la versión vulnerable: el aviso público no especificó el estado de n8n Cloud. Para referencias y detalles técnicos del aviso y del seguimiento, consulte la entrada del advisory en GitHub GHSA-gv7g-jm28-cr3m y la página de lanzamientos oficiales donde aparecen las versiones corregidas Releases de n8n en GitHub. Para contexto periodístico y reportes de terceros, puede revisar coberturas y análisis en medios especializados como The Hacker News thehackernews.com.

En resumen: actualice sin demora, no confíe sólo en mitigaciones administrativas, audite cambios recientes en workflows y secretos, y trate las cuentas de edición de workflows como activos críticos en su política de seguridad. La combinación de parches técnicos, restricciones de acceso y una respuesta forense rápida es la mejor defensa contra este tipo de escape del sandbox.