CVE-2026-59208 Enables Cross-Issuer Impersonation in n8n

AI and workflow automation platforms can connect identities directly to actions across email, cloud services, databases, and other business systems. When authentication maps a valid token to the wrong account, an attacker may inherit the permissions and connected resources assigned to that user.

CVE-2026-59208 is an identity-binding vulnerability affecting n8n Enterprise deployments that use token exchange with multiple trusted issuers. Under specific conditions, an attacker with a valid token from one trusted issuer could be authenticated as a user associated with another issuer.

What Is CVE-2026-59208?

CVE-2026-59208 is an improper authentication vulnerability in the token exchange functionality of n8n Enterprise. The issue occurred because n8n resolved external identities using only the JSON Web Token (JWT) subject claim, identified as sub, without also considering the issuer claim, iss.

A JWT subject identifies a user within the issuer’s identity system. However, the same subject value can exist under multiple issuers. The vulnerable logic effectively treated sub as globally unique, creating a collision risk when an n8n deployment trusted more than one token issuer.

A properly bound external identity should therefore use both values:

External identity = (iss, sub)

Without this issuer binding, a valid token issued for one identity domain could be mapped to an account belonging to another.

How Does CVE-2026-59208 Work?

The vulnerability does not bypass JWT signature verification or cause n8n to accept a token without a valid signature. Instead, it affects what happens after n8n accepts a token as valid.

A potential attack follows this sequence:

• An organization enables Enterprise token exchange and configures at least two trusted issuers.
• An attacker obtains a valid JWT from one of those issuers.
• The token contains a sub value matching a user registered under another trusted issuer.
• n8n resolves the identity using the matching sub without confirming that the user belongs to the token’s iss.
• The attacker receives a session associated with the other user’s n8n account.

The attack requires a valid token and a workable subject collision. However, if these conditions are met, the attacker could impersonate another n8n user without knowing that user’s password.

Key point: The token may be cryptographically valid while still being linked to the wrong local identity. Authentication systems must verify both who issued a token and which user the issuer identified.

Which n8n Versions Are Affected?

CVE-2026-59208 affects the following n8n versions:

The vulnerability only applies when:

• Enterprise token exchange is enabled
• Two or more trusted token-exchange issuers are configured
• An attacker possesses a valid token from one trusted issuer
• The token’s sub matches an account associated with another issuer

The trusted signing keys may be configured through settings such as N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, while token exchange must also be enabled separately.

Deployments that do not use token exchange or trust only one issuer are not exposed to the described cross-issuer condition. Nevertheless, affected organizations should upgrade instead of relying on their current configuration as a permanent safeguard.

Is CVE-2026-59208 Being Exploited?

As of July 16, 2026, there was no confirmed evidence of active exploitation and no publicly available proof-of-concept exploit had been identified.

The vulnerability is also configuration-dependent, which limits the number of exposed deployments. However, its prerequisites should not be mistaken for low impact. Organizations using the affected multi-issuer setup may expose high-value workflow accounts if a valid-token and subject-collision path exists.

The severity also differs between scoring systems:

• GitHub CNA: CVSS 4.0 score of 7.6 (High)
• NVD: CVSS 3.1 score of 6.8 (Medium)

The CNA vector reflects required attack conditions, low privileges, no user interaction, and potentially high confidentiality and integrity impact.

SOCRadar Vulnerability Intelligence

Using SOCRadar Vulnerability Intelligence with Attack Surface Management (ASM), security teams can monitor vulnerability developments, gain visibility into potentially exposed assets, and support risk-based remediation. For CVE-2026-59208, these capabilities can help teams assess whether n8n is present in their environment and prioritize further investigation.

Because exposure depends on Enterprise token exchange with multiple trusted issuers, findings should be confirmed through internal version and configuration checks.

What Should Defenders Do?

Upgrade n8n

Organizations should upgrade to one of the fixed versions or a later supported release:

• 2.27.4 or later for deployments on the 2.27 branch
• 2.28.1 or later for deployments on the 2.28 branch

After upgrading, test token exchange across every configured issuer. Validation should confirm that accounts sharing the same sub value cannot be mapped across separate issuers.

Review the Token Exchange Configuration

Determine whether token exchange is enabled and inspect the configured trusted issuers and signing keys.

Security teams should document:

• Every trusted issuer
• The business reason each issuer is required
• Which users and applications obtain tokens from each issuer
• Whether subject values can overlap between issuers
• Who is authorized to modify the trusted issuer configuration

Remove issuers that are no longer necessary and rotate trusted keys if unauthorized configuration changes are discovered.

Apply Temporary Mitigations

If upgrading cannot be completed immediately:

• Reduce the configuration to one trusted issuer, where operationally possible
• Disable token exchange if the feature is not required
• Restrict access to the n8n instance while remediation is underway
• Avoid adding new issuers until the fixed version has been deployed

These measures reduce exposure but should not replace the security update.

Claude for Chrome Flaw Highlights a Similar AI Action Risk

A separate vulnerability reported in Claude for Chrome further illustrates how AI tools can transform a narrow trust failure into actions across connected services.

The issue could allow a malicious Chrome extension with access to claude.ai to manipulate page elements and generate synthetic user interactions. By simulating clicks, the extension could trigger predefined Claude actions without the user deliberately initiating them.

The attack required the victim to install a malicious browser extension capable of running code on the Claude website. A regular website could not directly compromise the Claude extension through the reported technique. The risk came from combining the malicious extension’s ability to manipulate the page with Claude’s authenticated connections to services such as Gmail, Google Docs, Google Calendar, and Salesforce.

Although technically separate from CVE-2026-59208, the underlying security lesson is similar: AI and automation systems should not convert an insufficiently verified signal directly into trusted action.

• In n8n, a valid token could be associated with the wrong user.
• In Claude for Chrome, simulated interface activity could be mistaken for genuine user intent.
• In both cases, connected services could expand the consequences beyond the initially affected component.

Organizations deploying browser-based AI agents should restrict extension installations, review permissions granted to AI tools, minimize connected-service access, and require additional confirmation for sensitive actions. Read Manifold Security’s original Claude for Chrome research.

Timeline

• June 24, 2026: n8n released versions 2.27.4 and 2.28.1 containing the fix.
• July 9, 2026: CVE-2026-59208 became public.
• July 13, 2026: CISA-ADP added its SSVC assessment to the CVE record, reporting no known exploitation..
• July 16, 2026: Additional reporting documented the affected configuration, severity assessments, and absence of known exploitation.

Risk Assessment for AI Workflows

Likelihood: Environment-dependent. Exploitation requires Enterprise token exchange, multiple trusted issuers, a valid token, and a usable sub collision.

Impact: High in affected environments. Successful exploitation changes the user identity under which n8n access and workflow actions are performed.

Priority: Immediate for organizations running affected versions with multi-issuer token exchange. Other n8n deployments should still upgrade as part of their normal vulnerability-management process.

Conclusion

CVE-2026-59208 shows that verifying a token’s signature is only one part of secure authentication. The platform must also bind the token to the correct issuer and user.

Affected n8n Enterprise deployments should upgrade to version 2.27.4, 2.28.1, or a later supported release, review their trusted issuer configuration, and examine token exchange activity for cross-issuer identity anomalies. Organizations should also assess what each n8n account can reach because successful impersonation could extend into workflows, credentials, and connected business systems.

The n8n and Claude for Chrome issues affect different products and trust mechanisms, but both point to the same wider concern: when AI and automation tools can act across connected services, weak identity or intent validation can turn a small control failure into a much broader security event.