Se detectó una vulnerabilidad crítica (CVE-2026-59208) en la plataforma n8n que permitía la suplantación de identidad en cuentas Enterprise. El fallo ocurría al validar tokens JWT de múltiples emisores, ignorando el emisor y basándose solo en el identificador del usuario. n8n ya lanzó una corrección en las versiones 2.27.4 y 2.28.1, recomendando actualizar el sistema o limitar los emisores de tokens.



n8n, la plataforma de automatización de flujos de trabajo, entregaba las cuentas equivocadas al iniciar sesión. En instancias Enterprise configuradas para confiar en más de un emisor de tokens externos, relacionaba un JWT entrante con un usuario local basándose únicamente en la reclamación "sub" e ignoraba el "iss".

Un token válido del emisor A que llevara un "sub" perteneciente a alguien bajo el emisor B te permitía iniciar sesión como esa persona. Su contraseña nunca entró en juego. n8n lanzó la solución el 24 de junio.

El fallo está registrado como CVE-2026-59208. El registro del CVE no se hizo público hasta el 9 de julio. n8n atribuye el informe a la cuenta de GitHub bearsyankees bearsyankees, cuyo perfil menciona a Strix, que crea un agente de pruebas de penetración de IA.

Strix afirma que señaló el agente en el flujo de intercambio de tokens y encontró allí el error de vinculación de identidad.

Dos emisores, una cuenta

El intercambio de tokens es la ruta Enterprise de n8n para socios OEM que integran el producto como una integración OEM, una implementación de RFC 8693 según las notas de lanzamiento que evita a sus usuarios una segunda pantalla de inicio de sesión.

El socio firma un JWT de corta duración con su propia clave, n8n lo verifica contra una clave pública configurada, relaciona las reclamaciones con una cuenta local y el usuario entra. Las claves confiables se colocan en N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, y la documentación de despliegue todavía etiqueta la función como vista previa.

El token en sí es correcto. El error está en la coincidencia. Un valor "sub" solo tiene garantía de ser único dentro del emisor que lo creó. El RFC 7519 solicita que esté "limitado para ser localmente único en el contexto del emisor" o que sea globalmente único. Por lo tanto, el identificador de un usuario es el par: iss más sub.

n8n se basó en la mitad de ello. Nada impide que dos emisores emitan la misma cadena de sujeto, y cuando sucede, ambos aterrizan en una sola cuenta de n8n.

Qué tan grave es esto

El fallo afecta a una instancia solo si el intercambio de tokens está activado y la configuración confía en al menos dos emisores externos. n8n dice que nada más se ve afectado. El intercambio de tokens es exclusivo de Enterprise y aún está marcado como vista previa, por lo que el conjunto expuesto es pequeño y específico: despliegues OEM, donde confiar en un segundo emisor es una configuración soportada.

Lo que el aviso no aclara es cómo un atacante obtiene el token. Solo dice que pueden obtener uno. La pregunta práctica es si un usuario ordinario en un emisor confiable puede influir en el "sub" que recibe. El registro público no lo responde. El vector CVSS 4.0 de GitHub marca que existen requisitos de ataque y se detiene ahí.

GitHub asignó ese vector. Como CNA aquí, sitúa el CVE-2026-59208 en 7.6 en CVSS 4.0, nivel alto. NVD sitúa el mismo error en 6.8 en CVSS 3.1, nivel medio, y no ha emitido una evaluación 4.0; su registro incluye CWE-287 y CWE-346. La evaluación SSVC de CISA del 13 de julio registra la explotación como nula.

Dos semanas antes de la corrección del 24 de junio, los mantenedores parchearon el CVE-2026-54305, otro fallo exclusivo de Enterprise. Este permitía que cualquier usuario autenticado sobrescribiera o revocara los tokens OAuth almacenados de otro usuario a través de los endpoints de Credenciales Dinámicas. Aquello fue una falta de verificación de propiedad, no una vinculación de identidad. Error diferente, misma superficie.

Parchear o recortar la lista de emisores

El CVE-2026-59208 afecta a todas las versiones de n8n inferiores a la 2.27.4 y a la versión 2.28.0. La solución llegó primero en la 2.27.4 y 2.28.1. Esas son la base. El 16 de julio, el paquete npm de n8n llevaba la 2.30.6 en sus etiquetas más reciente y estable. Lanzan una nueva versión menor casi todas las semanas, así que comprueba la etiqueta y utiliza la versión estable más reciente que soporte tu despliegue.

Si el parcheado tiene que esperar, analiza qué estás ejecutando: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS contiene las claves de firma confiables, y un flag de vista previa independiente controla si el intercambio de tokens está activo. Reduce la configuración a un solo emisor confiable o desactiva la función.

El aviso sugiere ambas medidas a corto plazo y dice que ninguna remedia totalmente el riesgo. Eso es un texto estándar, idéntico en al menos otros tres avisos de n8n. Según la propia declaración de alcance de n8n, una instancia con el intercambio de tokens desactivado no se ve afectada.

Ninguna nota de lanzamiento menciona la corrección. The Hacker News revisó ambas: entre los registros de cambios de la 2.27.4 y la 2.28.1 se cubren una corrección de importación de Python, una actualización del nodo de Google Ads, una verificación de flujo de trabajo de IA y un cambio en la construcción de nodos, pero nada sobre la identidad.

El aviso es donde reside esta información. Si tus decisiones de actualización se basan en los registros de cambios, este es el tipo de corrección que se te podría pasar por alto.

Fuente:
THN