n8n, una plataforma de automatización del flujo de trabajo, distribuyó una cuenta incorrecta al iniciar sesión. En una instancia empresarial que se configuró para confiar en varios emisores de tokens externos, hicimos coincidir el JWT recibido con el usuario local solo en el reclamo secundario e ignoramos el problema.
Ha iniciado sesión como un token válido del emisor A que contiene una suscripción que pertenece a alguien del emisor B. Sus contraseñas nunca llegaron. n8n envió una versión revisada el 24 de junio.
Esta falla se rastrea como CVE-2026-59208. Los registros CVE no se publicaron hasta el 9 de julio. n8n atribuye este informe a la cuenta de GitHub Bearsyankees. El perfil de esta cuenta incluye a Strix, que crea agentes de pruebas de penetración de IA.
Strix dijo que el agente notó que había descubierto un error de vinculación de ID en el flujo de intercambio de tokens.
Dos editores, una cuenta
Token Exchange es la ruta empresarial de n8n para que los socios OEM integren sus productos y es una implementación RFC 8693 que elimina la necesidad de una segunda pantalla de inicio de sesión para los usuarios.
El socio firma el JWT de corta duración con su propia clave, n8n lo valida con la clave pública configurada, compara el reclamo con la cuenta local y el usuario se une. Las claves confiables se almacenan en N8N_TOKEN_EXCHANGE_TRUSTED_KEYS y la función todavía está etiquetada como vista previa en la documentación de implementación.
El token en sí está desprotegido. La coincidencia es un error. Se garantiza que los subvalores serán únicos solo dentro del editor que los creó. RFC 7519 requiere que su «alcance sea localmente único dentro del contexto del editor» o globalmente único. Por lo tanto, el identificador del usuario es un iss y un subpar.
n8n ingresó la mitad. No hay nada que impida que dos editores publiquen la misma cadena de asunto. Una vez publicados, ambos llegarán a una cuenta n8n.
¿Qué tan grande es esto?
Esta falla solo afecta a los casos en los que el intercambio de tokens está activado y la configuración confía en al menos dos emisores externos. n8n dice que no afecta nada más. El intercambio de tokens es solo empresarial y todavía está marcado como una vista previa, por lo que el conjunto público será pequeño y limitado. Esto significa que confiar en un segundo editor es una configuración admitida para implementaciones OEM.
Lo que el aviso no especifica es cómo un atacante obtendría los tokens. Solo dice que está disponible. La cuestión práctica es si los usuarios habituales de editores de confianza pueden influir en las suscripciones que reciben. Los documentos oficiales no responden a eso. El vector CVSS 4.0 de GitHub marca el requisito de ataque como presente y se detiene ahí.
GitHub asignó ese vector. CNA aquí tiene CVE-2026-59208 configurado en un valor alto de 7,6 con CVSS 4.0. NVD ha documentado el mismo error en 6.8 de CVSS 3.1 (medio) y no ha emitido ninguna evaluación para 4.0. Sus registros incluyen CWE-287 y CWE-346. La evaluación SSVC de CISA del 13 de julio no registró exploits y The Hacker News no encontró pruebas de concepto publicadas en una búsqueda del 16 de julio.
Dos semanas antes de la corrección del 24 de junio, los administradores parchearon otra falla exclusiva para empresas, CVE-2026-54305. Esto permite a un usuario autenticado sobrescribir o revocar el token de OAuth guardado de otro usuario a través del punto final de credenciales dinámicas. A esto le faltaba una verificación de propiedad, no un vínculo de identidad. Diferentes bichos, misma superficie.
Hacker News se comunicó con n8n para confirmar el alcance y el impacto de CVE-2026-59208 y actualizará este artículo si recibimos una respuesta.
Parchea o elimina tu lista de editores
CVE-2026-59208 afecta a todas las versiones de n8n anteriores a la 2.27.4 y la versión 2.28.0. Esta solución se aplicó por primera vez en 2.27.4 y 2.28.1. Ese es el piso. El 16 de julio, los paquetes npm para n8n incluyeron 2.30.6 para etiquetas modernas y estables. Enviamos nuevos mineros por nuestra cuenta casi todas las semanas, así que verifique las etiquetas para obtener la última versión estable que admita su implementación.
Si tiene que esperar a que se aplique el parche, descubra lo que está haciendo. N8N_TOKEN_EXCHANGE_TRUSTED_KEYS contiene claves de firma confiables y otro indicador de vista previa controla si el intercambio de tokens está activado. Limítelo a un único editor confiable o desactive la función.
Las recomendaciones describen ambas como medidas a corto plazo y dicen que ninguna remediará completamente el riesgo. Esto es un texto repetitivo y es lo mismo en al menos otras tres recomendaciones de N8N, incluida la recomendación del 10 de junio. Debido a la declaración de alcance única de n8n, los casos en los que el intercambio de tokens está desactivado no se ven afectados.
Ninguna nota de la versión menciona ninguna corrección. Hacker News comprobó ambos. Los registros de cambios para 2.27.4 y 2.28.1 incluyen correcciones de importación de Python, actualizaciones de nodos de Google Ads, comprobaciones del flujo de trabajo de IA y cambios en la construcción de nodos, pero nada sobre las ID.
La recomendación es dónde vive esta persona. Si las decisiones de actualización se toman basándose en registros de cambios, este es el tipo de solución que pasará desapercibida.
Source link
