n8n曝跨发行人账户接管漏洞CVE-2026-59208

背景

n8n 是一个开源的工作流自动化平台，允许用户通过可视化界面连接各种应用和服务，实现任务自动化。它被广泛用于企业级数据管道、API 编排和集成场景。由于 n8n 支持多租户部署（尤其是自托管版本中多个独立用户或组织共享同一实例），身份验证和授权机制的健壮性至关重要。

2025年6月，安全研究员 Strix 在 Hacker News 上披露了一个编号为 CVE-2026-59208 的漏洞，标题为 "Same Subject, Wrong User: A Cross-Issuer Account Takeover in n8n"。该漏洞属于跨颁发者账户接管（Cross-Issuer Account Takeover）类型，意味着攻击者可能利用身份验证系统的缺陷，以其他用户的身份执行操作，从而获取对目标账户的完全控制。

核心内容

根据 Strix 的披露，该漏洞源于 n8n 在处理身份验证令牌（Token）颁发者（Issuer）字段时的逻辑缺陷。在 OAuth 2.0 或 OpenID Connect 等标准协议中，令牌通常包含一个 iss（颁发者）声明，用于标识令牌的签发方。当 n8n 实例配置了多个身份提供者（例如多个 OAuth 应用或外部认证源）时，系统未能正确验证令牌的 iss 是否与当前请求的预期颁发者匹配。攻击者可以构造一个由其他身份提供者签发的有效令牌，但将其用于目标用户所属的颁发者上下文，从而绕过身份验证检查。

具体来说，攻击场景如下：

• 假设 n8n 实例同时集成了两个不同的 OAuth 应用（如 Google Workspace 和 Microsoft Entra ID），每个应用对应不同的 iss 值。
• 攻击者首先通过某个身份提供者（例如自己的 Google 账号）获取一个有效的访问令牌。
• 该令牌的 iss 指向攻击者自己的身份提供者，但 n8n 的认证逻辑未能将 iss 与目标用户所关联的提供者进行严格绑定。攻击者可将该令牌提交给 n8n，并声称其属于目标用户在另一个提供者下的会话。
• 由于 n8n 仅验证了令牌的签名和基本有效性，而未检查 iss 是否与当前请求的租户（Tenant）或用户上下文一致，导致系统错误地认为该令牌有效，并授予攻击者目标用户的权限。

该漏洞的严重性被标记为高危（Critical），因为它允许未经授权的账户接管，攻击者可以读取、修改或删除目标用户的工作流、凭证、联系人等敏感数据。n8n 官方已在后续版本中修复了该问题，修复方式为在认证中间件中添加对 iss 声明的严格校验，确保令牌的颁发者必须与当前请求绑定的身份提供者完全一致。

关键要点

• 漏洞编号：CVE-2026-59208，由 Strix 发现并报告至 Hacker News。
• 影响范围：n8n 版本（具体版本号未在原始披露中明确，但建议所有使用多身份提供者或 OAuth 集成的部署立即升级至最新修补版本）。
• 漏洞类型：跨颁发者账户接管（Cross-Issuer Account Takeover），属于身份验证逻辑缺陷。
• 根本原因：n8n 在处理 OAuth 令牌时未验证 iss 声明是否与当前请求的预期颁发者匹配，导致来自不同身份提供者的令牌可被交叉使用。
• 攻击前提：目标 n8n 实例配置了至少两个不同的身份提供者（例如多个 OAuth 应用或不同 SSO 源）。
• 潜在后果：攻击者可以完全接管目标用户账户，访问工作流、凭证、API 密钥、部署配置等敏感资源。
• 修复措施：n8n 官方已发布安全更新，强化了颁发者验证逻辑，建议用户立即升级。
• 披露时间：2025年6月（基于 Hacker News 发布时间）。

意义与影响

该漏洞的曝光揭示了低代码 / 无代码自动化平台在身份认证领域的一个常见盲点：当系统支持多个外部身份提供者时，开发者往往只关注令牌的签名验证，而忽略了对颁发者上下文（Issuer Context）的绑定。这种缺陷在 SaaS 多租户架构、开源自托管产品以及企业级集成平台中尤为危险，因为攻击者可能利用一个低权限的第三方账号（如普通 Google 账号）来获取对高价值目标（如企业管理员账户）的访问。

对于 n8n 用户而言，CVE-2026-59208 提醒了以下几点：

• 自托管用户应尽快检查 n8n 实例是否使用了多身份提供者，并应用官方补丁。
• 即使只有一个身份提供者，也建议升级以获得通用安全改进。
• 企业应审查其身份认证策略，确保所有 OAuth / OIDC 集成都执行了严格的颁发者与租户绑定。

从行业角度看，该漏洞与近年来日益增多的“跨代理 / 跨租户身份绕过”攻击（如 Snowflake 的跨租户攻击、Okta 的跨账户接管）具有相似性，表明云原生应用的身份验证模型需要更细致的上下文控制。未来，开源项目在引入多身份提供者支持时，应借鉴“认证上下文强制执行”模式，将 iss、aud（受众）和 sub（主体）组合为不可篡改的绑定三元组，以防止此类交叉授信攻击。