n8n 这个高危漏洞提醒开发者：JWT 只看 `sub`，真的会认错人
作者：韩启明｜OC 政策与安全编辑
韩启明
安全公司 Strix 披露，n8n 的 token exchange 流程曾存在跨发行者账户接管漏洞 CVE-2026-59208。系统会正确验证 JWT 由哪个可信发行者签发，却在把令牌映射到本地用户时只使用 sub，没有把 iss 一起纳入身份键。漏洞已在 n8n 2.28.1 和 2.27.4 中修复。
一句话结论：签名验证通过只能说明令牌是真的，不能说明不同身份系统里的同一个用户编号代表同一个人。
这个漏洞之所以值得开发者细看，是因为每一段代码单独看都很合理。验证层检查了签名、kid、iss、audience 和算法；身份层也拿到了标准的 sub 字段。问题出在两个模块的接缝：身份层丢掉了发行者，只按 sub 查找本地账户。
假设公司同时信任发行者 A 和 B。A 里的用户编号 12345 属于财务负责人，B 里恰好也有一个 12345。两个令牌都合法，但如果 n8n 把它们都映射到同一个本地身份，B 的持有者就可能进入 A 用户的工作流、凭证和数据。
修复思路并不复杂：把发行者和主体绑定在一起。n8n 使用发行者哈希与 sub 组成限定后的 provider ID，让 (iss, sub) 而不是单独的 sub 成为身份。代码改动可以很小，影响却很大，因为 n8n 往往位于自动化系统中心，连接数据库、邮箱、云服务和各种密钥。
这也是为什么安全问题不能只靠静态规则扫描。令牌验证函数没有明显错误，账户查询函数也能正常工作；只有沿着完整登录流程去看“验证后的身份如何落到本地账户”，才能发现两个信任域被错误折叠。Strix 还用两个发行者、不同签名密钥和相同 sub 的集成测试复现了问题。
OC 的判断是，这不是 n8n 独有的粗心，而是一类很常见的身份建模错误。凡是接入多个 OIDC、企业 SSO 或 token exchange 来源的系统，都应该检查数据库里保存的是裸 sub，还是带发行者范围的稳定标识。
为什么重要：
- 对开发者：外部身份的唯一键通常应是
(issuer, subject)，不能默认sub全局唯一。 - 对企业：运行 n8n token exchange 的实例应尽快升级，并检查是否配置了多个可信发行者。
- 对用户：自动化平台一旦被接管，暴露的不只是账户本身，还有它保存和调用的下游凭证。
参考来源：
评论
围绕这篇文章补充信息、提出问题或分享观察。