La falla en el intercambio de tokens n8n podría permitir a los atacantes iniciar sesión como usuarios de otro emisor – CYBERDEFENSA.MX
n8n, la plataforma de automatización del flujo de trabajo, entregó las cuentas equivocadas al iniciar sesión. En instancias empresariales configuradas para confiar en más de un emisor de token externo, hizo coincidir un JWT entrante con un usuario local en el sub reclamo solo e ignorado iss.
Un token válido del emisor A que lleva un sub que pertenece a alguien del emisor B, inició sesión como esa persona. Su contraseña nunca apareció. n8n envió la solución el 24 de junio.
El defecto se rastrea como CVE-2026-59208. El registro CVE no se hizo público hasta el 9 de julio. n8n acredita el informe a la cuenta de GitHub ososyankeescuyo perfil incluye a Strix, que fabrica un agente de pruebas de penetración de IA.
estrix dice Señaló que el agente en el flujo de intercambio de tokens encontró el error de vinculación de identidad allí.
Dos emisores, una cuenta
El intercambio de tokens es la ruta empresarial de n8n para Socios OEM que integran el productoun Implementación de RFC 8693 eso ahorra 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 con una clave pública configurada, hace coincidir los reclamos con una cuenta local y el usuario está dentro. Las claves confiables entran N8N_TOKEN_EXCHANGE_TRUSTED_KEYSy el documentos de implementación aún etiquete la función como vista previa.
El token en sí se verifica. La coincidencia es el error. A sub Solo se garantiza que el valor será único dentro del emisor que lo acuñó. RFC 7519 pide que «tenga un alcance para ser localmente único en el contexto del emisor» o globalmente único. El identificador de un usuario es, por tanto, el par, iss más sub.
n8n codificado en la mitad. Nada impide que dos emisores emitan la misma cadena de asunto y, cuando lo hacen, ambos aterrizan en una cuenta n8n.
¿Qué tan importante es esto?
La falla alcanza una instancia solo si el intercambio de tokens está activado y la configuración confía en al menos dos emisores externos. n8n dice nada más se ve afectado. El intercambio de tokens es solo empresarial y todavía está marcado como una vista previa, por lo que el conjunto expuesto es pequeño y específico: implementaciones OEM, donde confiar en un segundo emisor es una configuración admitida.
Lo que el aviso no especifica es cómo un atacante obtiene el token. Sólo dice que pueden obtener uno. La cuestión práctica es si un usuario normal de un emisor de confianza puede influir en la sub ellos reciben. El registro público no lo contesta. El vector CVSS 4.0 de GitHub marca los requisitos de ataque como presentes y se detiene allí.
GitHub asignó ese vector. Como aquí la CNA pone CVE-2026-59208 a 7.6 en CVSS 4.0, alto. NVD coloca el mismo error en 6.8 en CVSS 3.1, medio, y no ha emitido ninguna evaluación de 4.0; su registro lleva CWE-287 y CWE-346. La evaluación SSVC de CISA del 13 de julio registra ninguna explotación, y The Hacker News no encontró ninguna prueba pública de concepto en las búsquedas del 16 de julio.
Dos semanas antes de la corrección del 24 de junio, los mantenedores parchearon CVE-2026-54305otro defecto exclusivo de Enterprise. Permite que cualquier usuario autenticado sobrescriba o revoque los tokens OAuth almacenados de otro usuario a través de los puntos finales de Credenciales dinámicas. Ése era un control de propiedad faltante, no una vinculación de identidad. Bicho diferente, misma superficie.
The Hacker News se ha puesto en contacto con n8n para obtener confirmación sobre el alcance y el impacto de CVE-2026-59208 y actualizará esta historia con cualquier respuesta.
Parchear o cortar la lista de emisores
CVE-2026-59208 afecta a todas las versiones de n8n inferiores a 2.27.4 y 2.28.0. La solución llegó por primera vez a 2.27.4 y 2.28.1. Esos son el piso. El 16 de julio, el paquete npm de n8n llevaba la versión 2.30.6 en ambos latest y stable etiquetas. Envía un nuevo menor la mayoría de las semanas por su propia cuenta, así que verifique la etiqueta y tome la versión estable más nueva que admita su implementación.
Si la aplicación de parches tiene que esperar, averigüe qué está ejecutando: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS contiene las claves de firma confiables y un indicador de vista previa independiente controla si el intercambio de tokens está activado. Vuelva a centrarse en un único emisor de confianza o desactive la función.
El aviso llama a ambas medidas a corto plazo y dice que ninguna remedia completamente el riesgo. Esto es un texto repetitivo, idéntico en al menos otros tres avisos de n8n, incluido el del 10 de junio. Según la propia declaración de alcance de n8n, una instancia con intercambio de token desactivado no se ve afectada.
Ninguna nota de la versión menciona la solución. The Hacker News comprobó ambos: entre ellos, el 2.27.4 y 2.28.1 Los registros de cambios cubren una corrección de importación de Python, una actualización de un nodo de Google Ads, una verificación del flujo de trabajo de IA y un cambio en la creación de nodos, y nada sobre la identidad.
El aviso es donde éste vive. Si sus decisiones de actualización se basan en registros de cambios, este es el tipo de solución que pasa desapercibida.
