n8n autoalojado: las vulnerabilidades críticas de septiembre 2026 y qué hacer si tienes una instancia propia

El 2 de septiembre de 2026, n8n publicó 18 avisos de seguridad de golpe: 5 de severidad alta y 13 de severidad media. Dos de los altos tienen una puntuación CVSS de 8.7 sobre 10. Si usas n8n en la nube de n8n, no tuviste que hacer nada — el proveedor lo parcheó por ti. Si tu instancia es autoalojada, que es exactamente lo que promete el control total sobre tus datos, actualizar depende de ti. Y a día de hoy, más de una semana después, es fácil que todavía no lo hayas hecho porque nadie te avisó.

Lo que se corrigió el 2 de septiembre

La corrección llegó en tres ramas a la vez: v1.123.76 (rama v1), v2.37.7 (rama estable) y v2.38.2 (rama beta). Cualquier instalación por debajo de esas versiones sigue expuesta a los 18 fallos publicados ese día, verificados directamente en las advisories del repositorio de n8n en GitHub.

De los 18, dos merecen atención inmediata porque no requieren casi nada por parte de un atacante para explotarlos.

CVE-2026-86076 — fuga del sandbox de expresiones (CVSS 8.7)

n8n ejecuta las expresiones de los workflows (los {{ }} que rellenan campos con datos dinámicos) dentro de un sandbox pensado para que ese código no pueda salirse de su caja. El fallo estaba en cómo el compilador de expresiones resolvía su propio saneador: lo hacía a través de un this con alcance dinámico, así que bastaba con nombrar un campo de clase __sanitize dentro de una expresión para redirigir ese this y llegar hasta el constructor Function. Desde ahí, ejecución de código arbitrario.

Tiene dos superficies distintas, y la segunda es la que se suele pasar por alto:

• En el servidor: cualquiera que pueda escribir una expresión en un workflow puede ejecutar código dentro del proceso de n8n — no solo dentro del workflow, en el proceso entero.
• En el navegador de quien revisa el workflow: la vista previa del editor evalúa esa misma expresión para mostrar el resultado. Si un compañero abre un workflow con una expresión maliciosa dentro, ese código corre en la sesión de ese compañero, no en la de quien lo escribió.

Esto último es lo que lo hace peligroso incluso en instancias donde "solo confío en la gente que tiene acceso": si esa gente incluye a alguien con permiso para crear o editar workflows —un colaborador, un cliente al que le diste acceso limitado, un contratista temporal—, ese permiso ya es suficiente para comprometer a cualquier otra persona que abra ese workflow después.

CVE-2026-86075 — agotar tu base de datos sin necesitar ni una cuenta (CVSS 8.7)

Este es el que más debería preocupar a cualquiera que exponga su instancia a internet, porque no exige autenticación de ningún tipo. Los endpoints de registro dinámico de clientes OAuth validaban el tamaño del campo redirect_uris, pero no el de client_name ni grant_types — solo comprobaban que existieran, no cuánto pesaban.

Un atacante sin cuenta puede llamar a ese endpoint una y otra vez con valores enormes en esos dos campos. Cada llamada se guarda en la base de datos sin límite de tamaño. Repetido lo suficiente, agota el almacenamiento persistente y tira la instancia por denegación de servicio — sin necesitar credenciales, sin necesitar que nadie haga clic en nada.

Qué hacer ahora mismo si tienes n8n autoalojado

• Comprueba tu versión y actualiza a v1.123.76, v2.37.7 o v2.38.2 según la rama que uses. Es la única corrección real; todo lo demás es parche temporal.
• Si no puedes actualizar hoy, para el fallo del sandbox: restringe quién tiene permiso para crear o editar workflows a gente de confianza real, audita los workflows existentes buscando campos de clase sospechosos como __sanitize, y como mitigación temporal puedes fijar N8N_EXPRESSION_ENGINE=vm.
• Para el fallo de OAuth: si tu instancia es accesible desde internet, pon un proxy inverso delante con límite de tamaño de petición, y vigila el crecimiento de la tabla oauth_clients — un crecimiento anómalo es la señal de que ya te lo están explotando.
• No des por hecho que "mi instancia es pequeña, a nadie le interesa". El segundo fallo no discrimina por tamaño: un script que barre internet buscando instancias n8n expuestas no distingue entre una pyme y una multinacional.

Esto no es un caso aislado, y conviene asumirlo

No es la primera vez este año que n8n publica una vulnerabilidad crítica con ejecución remota de código. En febrero de 2026 ya hubo otra corrección de ese calibre en versiones anteriores a la 1.123.17 y 2.5.2. La lectura correcta no es "n8n es inseguro" — es una plataforma de código abierto con una base de instalaciones cada vez mayor, y eso significa más gente auditando el código en busca de fallos, tanto para reportarlos como, en el peor caso, para explotarlos antes de que se publique el parche. Autoalojar n8n para tener control total de tus datos es una decisión que sigue teniendo sentido, pero control total también significa que la responsabilidad de vigilar estos avisos y aplicar los parches es tuya, no de un proveedor que lo hace en segundo plano mientras duermes.

Es el mismo principio que ya vimos al hablar de un fallo silencioso en una integración de WhatsApp: un sistema en producción no avisa solo porque algo vaya mal. Alguien tiene que estar mirando activamente — logs, avisos de seguridad, changelogs de las dependencias — porque el sistema, por sí solo, no te va a decir que tiene un problema hasta que ese problema ya te ha costado algo.