GHSA-9x83: cuando editar un workflow de n8n se convierte en ejecución de código en el host

En una plataforma de automatización, dar a alguien permiso para editar workflows no debería equivaler a entregarle una shell en el servidor. El advisory GHSA-9x83-43r8-5hwc mostró exactamente esa ruptura de frontera en n8n: una expresión creada por un usuario con privilegios para construir workflows podía escapar del entorno de evaluación y compilar código dentro del proceso principal. El resultado potencial es el compromiso completo de la instancia que concentra credenciales, webhooks y conexiones con otros sistemas.

Lo que confirma el advisory

El mantenedor publicó el GHSA el 19 de agosto de 2026 con severidad alta y CVSS 4.0 de 8,7. El vector oficial es CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N: ataque por red, baja complejidad, ninguna condición adicional, bajo privilegio y ninguna interacción de otra persona. A la fecha de este texto, el advisory no asocia una CVE con la falla, por eso usamos el identificador GHSA en lugar de crear una referencia inexistente.

• La línea 1.x está corregida en 1.123.73.
• La línea estable 2.35 está corregida en 2.35.4.
• La línea beta 2.36 está corregida en 2.36.2.
• Las instancias de n8n Cloud fueron actualizadas automáticamente, según el boletín del proveedor.
• Las instancias self-hosted por debajo de la corrección de su línea deben ser actualizadas por el operador.

Cómo una propiedad heredada atravesó el sandbox

La causa está en una pequeña distinción de JavaScript que tiene un gran efecto en fronteras de seguridad. Al resolver un nombre de placeholder proporcionado por el llamador, `$fromAI` no exigía que la clave fuera una propiedad propia del objeto y también aceptaba claves reservadas. En JavaScript, buscar una clave sin esa verificación puede continuar por la cadena de prototipos. Frente a un valor primitivo, esa resolución devolvía una referencia viva a un prototipo del entorno host.

Desde esa referencia, una expresión podía caminar hasta el constructor `Function`. Ese constructor compila código JavaScript y el código dejaba de ejecutarse dentro del modelo restringido esperado para la expresión. El punto decisivo no es solamente obtener un objeto inesperado. Es obtener un objeto que todavía pertenece al proceso host y conserva un camino hasta una capacidad de ejecución.

• Aceptar nombres de propiedad controlados por el usuario amplía la entrada mucho más allá de los campos previstos.
• Bloquear algunos nombres peligrosos es insuficiente si la resolución todavía recorre propiedades heredadas.
• Copiar datos a estructuras sin prototipo y exigir propiedades propias reduce esta clase de confusión.
• Los objetos que atraviesan la frontera del sandbox no pueden conservar referencias vivas a constructores o prototipos del host.
• Las pruebas de seguridad deben incluir claves reservadas, valores primitivos y caminos de prototipo, no solo expresiones comunes.

Por qué bajo privilegio todavía significa alto impacto

El requisito es una cuenta autenticada capaz de construir o editar workflows. Esto reduce el conjunto de atacantes, pero no reduce lo que ocurre después del escape. El código se ejecuta en el proceso principal de n8n y hereda los permisos del usuario de sistema, el acceso de red y los archivos disponibles para el servicio. En muchas instalaciones, ese proceso necesita llegar a bases de datos, colas, APIs internas y servicios externos para que las automatizaciones funcionen.

Por eso, el permiso para editar workflows debe tratarse como privilegio de desarrollo sobre un sistema sensible, no como acceso común de negocio. La documentación de n8n señala que los editores pueden ejecutar workflows y usar las credenciales ya vinculadas a ellos, incluso cuando la credencial no fue compartida directamente. La falla agregaba una ruta para salir de esa delegación controlada y alcanzar el entorno que guarda las integraciones.

Actualiza y confirma el runtime

La corrección es actualizar a 1.123.73, 2.35.4, 2.36.2 o una versión posterior dentro de la línea adoptada. En un despliegue self-hosted, no basta con cambiar la etiqueta en el repositorio o completar el pipeline. Confirma la versión del contenedor en ejecución, alinea componentes como workers y runners y verifica que réplicas antiguas ya no atiendan tráfico.

# Exemplo para uma implantacao Docker Compose cujo servico se chama n8n
docker compose pull n8n
docker compose up -d n8n
docker compose exec n8n n8n --version

# Auditoria defensiva documentada pelo n8n
docker compose exec n8n n8n audit

El comando `n8n audit` no prueba que la falla haya sido explotada ni sustituye una investigación. Ayuda a localizar riesgos que aumentan el impacto, como nodos con acceso al sistema de archivos, nodos oficiales de alto riesgo, community nodes, webhooks sin protección, configuraciones de seguridad ausentes e instancia desactualizada. Usa el resultado para revisar el radio de alcance después del parche.

Si el parche no puede entrar ahora

El advisory deja claro que los controles temporales no corrigen la vulnerabilidad. Hasta la actualización, restringe la instancia a usuarios completamente confiables, deshabilita recursos y nodos relacionados con IA cuando no sean necesarios y ejecuta el proceso con una cuenta de sistema dedicada y de bajo privilegio. También conviene eliminar el acceso directo desde internet, limitar la salida de red y revisar qué proyectos realmente necesitan editores.

• Retira temporalmente la capacidad de editar workflows de las cuentas que no la necesitan.
• Deshabilita recursos de IA no utilizados y registra la excepción con fecha de vencimiento.
• Separa credenciales por proyecto y reduce permisos en el servicio de destino, no solo en n8n.
• Ejecuta n8n como usuario sin privilegios, con sistema de archivos y red limitados a lo necesario.
• Revisa logs de autenticación, cambios de workflow, ejecuciones inusuales y conexiones de salida del periodo anterior al parche.
• Rota secretos si existe evidencia de ejecución no autorizada o si la telemetría no permite descartar esa posibilidad.

Lo que un pentest debe validar además de la versión

Un escáner identifica la versión vulnerable. Un pentest contextual debe probar el modelo de confianza que hizo tan alto el impacto: quién recibe el rol de editor, qué credenciales están disponibles por proyecto, qué nodos permiten código o acceso a archivos, a qué destinos llega el proceso y si una ejecución anómala aparece en la telemetría. La pregunta útil no es solo si el GHSA fue corregido, sino si otra falla en el editor encontraría el mismo camino libre hasta producción.

• Mapear roles globales, proyectos, recursos compartidos y cuentas sin uso reciente.
• Validar el aislamiento entre proyectos y el uso indirecto de credenciales en workflows compartidos.
• Inventariar nodos de código, sistema de archivos, Git, shell, community nodes y herramientas de IA.
• Probar controles de salida hacia bases de datos, APIs internas, endpoints de metadatos y servicios en la nube.
• Confirmar que cambios sensibles, ejecuciones y accesos a secretos generen logs útiles y alertas accionables.
• Reprobar con una cuenta autorizada de bajo privilegio, sin ejecutar un payload destructivo en producción.

La lección de GHSA-9x83-43r8-5hwc es mayor que un bug en `$fromAI`. Las plataformas de automatización reúnen código configurable, identidad, secretos y conectividad en el mismo plano. Cuando un sandbox falla, todas esas capacidades definen el impacto. Corregir la versión cierra esta ruta. Reducir privilegios y alcance limita la próxima.