n8n Enterprise bajo alerta: fallo de enlace de identidad entre emisores de confianza podría permitir iniciar sesión como otro usuario

n8n, la plataforma de automatización de flujos de trabajo, parcheó a finales de junio un fallo serio que permitía iniciar sesión como otro usuario sin conocer su contraseña cuando la instancia Enterprise tenía activada la función de "token exchange" y confiaba en más de un emisor externo. En términos técnicos la raíz del problema fue un enlace de identidad incorrecto: el sistema comparaba únicamente la claim "sub" del JWT entrante con usuarios locales y no tomaba en cuenta el "iss" (issuer)RFC 7519, y el flujo de intercambio de tokens que n8n implementa sigue RFC 8693.

En la práctica la falla significaba que un token legítimo firmado por un emisor A que incluía un "sub" igual al de un usuario creado por el emisor B podía ser aceptado por n8n como si fuera ese otro usuario. El vector de ataque concreto que permitiría a un atacante obtener un token válido no está explicitado en el aviso público; eso deja incertidumbre sobre si un usuario normal en uno de los emisores podría forzar o conseguir un "sub" determinado. Las bases de datos públicas de vulnerabilidades reflejan evaluaciones distintas: el CNA asignó una puntuación alta en CVSS 4.0 mientras que NVD lo catalogó con una gravedad menor en CVSS 3.1. CISA ha registrado la incidencia y, de momento, no ha confirmado explotación activa en campo.

El alcance técnico es, sin embargo, bastante preciso: solo afecta a despliegues Enterprise que tengan activado el token exchange y que confíen en al menos dos claves emisoras configuradas en la variable N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. Es decir, la superficie expuesta es reducida y suele corresponder a implementaciones OEM o integradas donde n8n acepta tokens firmados por socios. n8n distribuyó el arreglo en versiones concretas del producto; si su entorno usa una versión anterior conviene considerarla vulnerable hasta que se actualice.

Si usted administra o depende de una instancia n8n Enterprise, las acciones prioritarias son claras y urgentes: primero, verifique la versión que está corriendo y planifique la actualización al parche más reciente que incluya la corrección. En paralelo, si no puede parchear de inmediato, reduzca la exposición desactivando la función de token exchange o restringiendo la configuración para confiar únicamente en un único emisor. Localice y revise la variable N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, confirme quiénes son los emisores de confianza y, si procede, retire entradas innecesarias hasta que se pueda aplicar la solución definitiva. Estas medidas de mitigación son temporales y, como advierten los avisos técnicos, no sustituyen la actualización del software.

Más medidas complementarias de defensa incluyen reforzar la telemetría y los registros: habilite y revise los logs de autenticación y de token exchange en busca de inicios de sesión inusuales, implemente alertas para sesiones recién creadas con identidades externas, active autenticación multifactor para las cuentas locales con privilegios y reduzca permisos innecesarios en workflows y credenciales. Si su despliegue admite registros de auditoría externos o SIEM, exporte esos eventos para una correlación más amplia y para facilitar una investigación posterior.

Esta vulnerabilidad no llega aislada: en las semanas previas n8n corrigió otro fallo Enterprise distinto que permitía manipular credenciales OAuth a través de endpoints de credenciales dinámicas, lo que sugiere que los despliegues con funcionalidades preview o integraciones OEM merecen una revisión particular y continuada. Para seguir las comunicaciones oficiales y los parches conviene no fiarse solo de los changelogs habituales: el arreglo concreto de identidad no siempre aparece en las notas de cambios de los paquetes, y la información oficial puede residir en el aviso de seguridad o la base de CVE. Mantenga un seguimiento activo de las fuentes del proveedor y de los repositorios de vulnerabilidades públicos como NVD y la documentación de producto en la documentación de n8n.

Finalmente, evalúe la necesidad de comunicar a los usuarios afectados y de iniciar un análisis forense si hay indicios de accesos no autorizados. Aunque no hay prueba pública de explotación masiva por ahora, el vector permite acceso sin contraseña en condiciones concretas, y cualquier exposición de credenciales o ejecuciones inesperadas de workflows debe tratarse como incidente potencial. La lección operativa es clara: cuando confía en tokens externos, el código de enlace de identidades debe respetar completamente el modelo iss+sub y las implementaciones que simplifican esa verificación están en riesgo. Revisar la configuración, aplicar parches y mejorar la monitorización son pasos indispensables para mitigar el problema.