n8n 令牌交换漏洞可使攻击者以其他签发方用户身份登录
导语：n8n 工作流自动化平台企业版的令牌交换功能存在身份绑定缺陷 CVE-2026-59208，在配置了多个外部令牌签发方时，仅根据 JWT 的 sub 声明匹配本地用户而忽略 iss 声明，可导致跨签发方身份混淆登录。
n8n 工作流自动化平台在登录环节出现了错误的账户匹配。在被配置为信任多个外部令牌签发方的企业版实例上，它仅依据 JWT 中的 sub 声明去匹配本地用户，完全忽略了 iss 声明。来自签发方 A 的一个有效令牌，只要其 sub 属于签发方 B 下的某位用户，就能让你以该用户的身份登录。整个过程中，对方的密码从未参与验证。n8n 已于 6 月 24 日发布了修复版本。
该漏洞编号为 CVE-2026-59208，对应的 CVE 记录直到 7 月 9 日才公开披露。n8n 将漏洞报告归功于 GitHub 账户 bearsyankees，其个人资料显示其所属 Strix 公司，该机构提供一款 AI 渗透测试代理工具。Strix 表示，他们指出了令牌交换流程中存在身份绑定缺陷。
令牌交换是 n8n 企业版为 OEM 合作伙伴提供的功能，这些合作伙伴将该产品嵌入到自己的方案中。该功能基于 RFC 8693 实现，可以让合作伙伴的用户免去再次登录的步骤。合作伙伴使用自己的密钥签署一个短期 JWT，n8n 使用已配置的公钥对其进行验证，然后将声明与本地账户匹配，用户即可登录。可信的密钥列表配置在 N8N_TOKEN_EXCHANGE_TRUSTED_KEYS 中，部署文档仍将该功能标记为预览版。
令牌本身的校验是正常的，问题出在匹配环节。sub 值仅在其签发方内部保证唯一性。RFC 7519 要求 sub 在签发方上下文内局部唯一，或者实现全局唯一。因此，一个用户的真正标识应该是 iss 加 sub 这对组合。n8n 仅使用了其中一半。当两个签发方发出相同的 sub 字符串时，两条令牌都会指向同一个 n8n 账户。
只有同时启用了令牌交换功能、且配置中至少信任两个外部签发方的实例才会受到该漏洞影响。n8n 表示，其他配置不受影响。由于令牌交换仅限企业版，且仍标记为预览版，因此受影响范围较小且具体：主要是那些将信任第二个签发方作为受支持配置的 OEM 部署。
公告中并未明确说明攻击者是如何获取令牌的，只表示他们可以拿到一个。实际的问题是，被信任签发方下的普通用户能否影响他们收到的 sub 值。公开记录并未回答这个问题。GitHub 的 CVSS 4.0 向量将攻击要求标记为存在，仅此而已。
该向量由 GitHub 分配。作为此 CVE 的 CNA，GitHub 将 CVE-2026-59208 在 CVSS 4.0 下评定为 7.6，高危。NVD 将同一漏洞在 CVSS 3.1 下评定为 6.8，中危，且尚未发布任何 4.0 评估；其记录带有 CWE-287 和 CWE-346。CISA 在 7 月 13 日的 SSVC 评估中记录利用状态为无，The Hacker News 在 7 月 16 日的搜索中也没有发现公开的概念验证代码。
在 6 月 24 日修复的两周前，维护者还修复了 CVE-2026-54305，这是另一个仅限企业版的漏洞。该漏洞允许任何已认证用户通过 Dynamic Credentials 接口覆盖或撤销其他用户存储的 OAuth 令牌。这是一处缺失的所有权检查，而非身份绑定缺陷。属于不同的漏洞，但攻击面相同。
The Hacker News 已就 CVE-2026-59208 的范围和影响联系 n8n 进行确认，并将根据任何回复更新本文。
CVE-2026-59208 影响 2.27.4 以下的所有 n8n 版本以及 2.28.0 版本。修复首次出现在 2.27.4 和 2.28.1 中，这就是最低修复版本。截至 7 月 16 日，n8n 的 npm 包在其 latest 和 stable 标签下均为 2.30.6。n8n 官方表示其通常每周都会发布一个新的次要版本，因此请检查标签，并选择你的部署环境所支持的最新稳定版本。
如果暂时无法升级，请先理清当前运行配置：N8N_TOKEN_EXCHANGE_TRUSTED_KEYS 中保存着受信任的签名密钥，另外还有一个独立的预览功能标志控制令牌交换是否启用。可以回退到只信任单一签发方，或者直接关闭该功能。
公告中将这两种短期缓解措施都列了出来，并表示两者都不能完全消除风险。这种表述属于模板化措辞，在至少三份其他 n8n 公告中也完全一致，包括 6 月 10 日的那份。按照 n8n 自己的范围声明，未启用令牌交换的实例不受影响。
两份发布说明中都没有提及此次修复。The Hacker News 已逐一核对：2.27.4 和 2.28.1 的更新日志合计仅涵盖了 Python 导入修复、Google Ads 节点升级、AI 工作流检查以及节点构建的相关变更，没有提及任何身份相关的内容。
本次漏洞的修复说明仅存在于安全公告之中。如果你的升级决策仅依赖更新日志，这种修复就很容易被忽略。
来源信息
来源：The Hacker News
原文链接：https://thehackernews.com/2026/07/n8n-token-exchange-flaw-could-let.html
作者：info@thehackernews.com (The Hacker News)
