En la plataforma de automatización de flujos de trabajo n8n se ha detectado la vulnerabilidad CVE-2026-59208, que permite a un atacante autenticarse bajo la cuenta de otra persona sin conocer la contraseña. El problema afecta a las instancias Enterprise con la función de intercambio de tokens (token exchange) habilitada y al menos dos emisores externos de JWT de confianza. El sistema asociaba el token entrante con un usuario local únicamente por el valor del claim sub, ignorando iss — el emisor del token. El parche se publicó el 24 de junio en las versiones 2.27.4 y 2.28.1; los administradores de las configuraciones afectadas deben actualizar o limitar el número de emisores de confianza a uno.
Esencia de la vulnerabilidad: la mitad del identificador en lugar del completo
La función de token exchange en n8n implementa la especificación RFC 8693 y está destinada a los socios OEM que integran n8n en sus productos. El socio firma un JWT de corta duración con su clave, n8n verifica la firma usando la clave pública previamente configurada en la variable de entorno N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, asigna los claims a una cuenta local y permite el acceso del usuario sin necesidad de autenticación adicional.
El problema residía en la lógica de asignación. Según el RFC 7519, el valor del claim sub está garantizado como único solo en el contexto de un emisor concreto (iss). El identificador correcto de usuario es el par iss + sub. Sin embargo, n8n utilizaba para el enlace únicamente sub, basándose de hecho en la mitad del identificador.
La consecuencia práctica es que, si dos emisores de confianza (A y B) emiten tokens con el mismo valor de sub para usuarios distintos, un token válido del emisor A permite autenticarse como el usuario registrado bajo el emisor B. La contraseña de la víctima no interviene en absoluto: el sistema confía plenamente en la asociación por sub.
Valoraciones de gravedad y estado de explotación
Las valoraciones de gravedad difieren según la fuente. GitHub como CNA ha asignado a la vulnerabilidad un CVSS 4.0 — 7.6 (High). La NVD la ha evaluado con CVSS 3.1 en 6.8 (Medium) y la ha asociado a las clases de debilidades CWE-287 (autenticación incorrecta) y CWE-346 (verificación insuficiente del origen). La discrepancia se explica tanto por las diferencias entre las metodologías CVSS 4.0 y 3.1 como por distintas interpretaciones de las condiciones de ataque.
La vulnerabilidad no se ha incluido en el catálogo CISA Known Exploited Vulnerabilities. Según los datos disponibles, no se han registrado pruebas de concepto (PoC) públicas ni casos confirmados de explotación.
Quién está en riesgo
El ámbito de impacto es reducido, pero las consecuencias son graves para las configuraciones afectadas. La vulnerabilidad se manifiesta solo cuando se cumplen simultáneamente tres condiciones:
- licencia Enterprise de n8n;
- función de token exchange activada (según la documentación, todavía en estado de preview);
- configuración con dos o más emisores externos de tokens de confianza.
Este es un escenario típico de despliegues OEM, donde varios socios integran n8n en sus plataformas. Para tales instancias, la vulnerabilidad equivale en la práctica a una posible toma de control de cuentas entre inquilinos distintos (cross-tenant): un usuario de un socio puede obtener acceso a los datos y flujos de trabajo de un usuario de otro socio.
Sigue abierta la cuestión de la viabilidad práctica del ataque: el advisory no aclara si un usuario normal de un emisor de confianza puede influir en el valor de sub de su token. El vector CVSS proporcionado por GitHub indica la existencia de requisitos adicionales para el ataque, pero no los detalla.
Contexto: segunda vulnerabilidad Enterprise en dos semanas
Dos semanas antes de publicar el parche para CVE-2026-59208, los desarrolladores de n8n corrigieron CVE-2026-54305, otra vulnerabilidad limitada a la funcionalidad Enterprise. Esta permitía a cualquier usuario autenticado sobrescribir o revocar los tokens OAuth de otros usuarios a través de los endpoints de Dynamic Credentials debido a la ausencia de comprobación del propietario del recurso. Se trata de dos vulnerabilidades diferentes —asociación de identidad y control de acceso a recursos—, pero ambas apuntan a una madurez insuficiente de las comprobaciones de autorización en los componentes Enterprise de la plataforma.
Recomendaciones para su corrección
Se ven afectadas todas las versiones de n8n anteriores a la 2.27.4, así como la versión 2.28.0. La corrección está disponible a partir de las versiones 2.27.4 y 2.28.1.
- Actualización: es la medida prioritaria. Instale como mínimo la versión 2.27.4 o 2.28.1, y preferiblemente la última compilación estable.
- Si la actualización no es posible de inmediato, reduzca la lista de emisores de confianza en
N8N_TOKEN_EXCHANGE_TRUSTED_KEYSa uno solo o desactive por completo la función de token exchange. Según declara n8n, las instancias con el token exchange desactivado no están expuestas a la vulnerabilidad. - Revise los registros de autenticación en busca de inicios de sesión anómalos: sesiones en las que un usuario se haya autenticado mediante un token de un emisor y haya obtenido acceso a recursos pertenecientes a la cuenta de otro.
Un matiz importante: ni en el changelog de la versión 2.27.4 ni en el changelog de la versión 2.28.1, según la información disponible, se menciona esta corrección. La información solo figura en el advisory. Las organizaciones que toman decisiones de actualización exclusivamente sobre la base de las release notes corren el riesgo de pasar por alto este parche.
Los administradores de n8n Enterprise con la función de token exchange activada y varios emisores de confianza deben considerar la actualización como urgente. Incluso con un alcance limitado de la vulnerabilidad, las consecuencias de su explotación —toma completa de la cuenta sin interacción con la víctima— hacen que cualquier demora resulte injustificada. Verifique la versión actual, el contenido de N8N_TOKEN_EXCHANGE_TRUSTED_KEYS y tome una decisión: actualizar o restringir la configuración.
