Cross‑Issuer Token Exchange Vulnerability Enables Unauthorized User Logins

Key Takeaways

• n8n’s Enterprise token‑exchange feature incorrectly authenticated users by matching only the JWT sub claim, ignoring the iss (issuer) claim.
• The flaw (CVE‑2026-59208) lets an attacker with a valid token from one trusted issuer log in as any local user whose sub value coincidentally matches another issuer’s subject.
• Only instances that have token exchange enabled and trust more than one external issuer are affected; the feature is still marked as a preview and limited to OEM/Enterprise deployments.
• n8n released patches in versions 2.27.4 and 2.28.1; all earlier releases are vulnerable.
• Mitigation: upgrade to a patched version, or, if upgrading is impossible, reduce the trusted‑issuer list to a single key or disable token exchange entirely.
• The vulnerability carries a CVSS 4.0 score of 7.6 (high) per GitHub’s CNA, while NVD rates it 6.8 (medium) under CVSS 3.1. No public proof‑of‑concept has been observed as of the disclosure date.

Overview of the Vulnerability
On July 16 2026, security researcher bearsyankees (linked to the Strix AI penetration‑testing agent) reported that n8n’s Enterprise token‑exchange flow could be abused to log in as another user without needing their password. The issue stems from the service validating a JSON Web Token (JWT) presented by an external identity provider, but using only the sub (subject) claim to locate a matching local account. Because the sub value is only guaranteed to be unique within the scope of its issuer, two different issuers can legitimately issue tokens bearing the same sub string. When n8n trusts more than one external issuer, it conflates those tokens and grants access to the account associated with the first matching sub it finds, regardless of which issuer actually signed the token.

How Token Exchange Works in n8n
Token exchange is an Enterprise‑only, preview‑grade implementation of RFC 8693 designed for OEM partners who embed n8n into their own products. The partner signs a short‑lived JWT with its private key; n8n verifies the signature against a public key listed in the environment variable N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. After verification, the service extracts claims from the token and attempts to bind them to a local user account. In a correct implementation, the binding should consider both the iss (issuer) and sub claims together, forming a globally unique identifier. The partner’s users then gain access without a second login screen, streamlining the OEM experience.

Root Cause: Ignoring the Issuer Claim
The bug resides in the identity‑binding routine that followed signature verification. Instead of constructing a composite key from iss + sub, the code performed a lookup based solely on sub. Consequently, if Issuer A issued a token with sub: "alice" and Issuer B also issued a token with sub: "alice" (perhaps for a different user), n8n would treat both tokens as referring to the same local account—typically the first one encountered during the lookup. Because the verification step still confirmed the token’s signature against the correct public key, the flaw was purely logical: the service accepted a token as proof of identity for a user it did not actually represent.

Scope and Affected Deployments
The vulnerability is reachable only when two conditions are met: (1) the token‑exchange feature is enabled via the preview flag, and (2) the administrator has configured N8N_TOKEN_EXCHANGE_TRUSTED_KEYS to trust at least two distinct external signing keys. Token exchange is an Enterprise‑only capability, and the documentation still labels it as a preview, which limits the exposed audience to OEM partners and internal Enterprise deployments that have deliberately opted‑in to multiple issuers. n8n explicitly states that no other components or configurations are impacted by this defect.

Attack Vector and Exploitation
The advisory notes that an attacker must first obtain a valid JWT from any trusted issuer. It does not detail how such a token could be acquired, leaving open possibilities ranging from credential theft at the partner side to misuse of legitimate user tokens. The practical exploitability hinges on whether a user at a trusted issuer can influence or predict the sub value they receive; if the partner’s issuance process allows an attacker to secure a token with a chosen subject, the attack becomes straightforward. As of July 16, no public proof‑of‑concept or exploit script has been observed, and CISA’s SSVC assessment recorded exploitation status as “none.”

CVSS Scores and Severity Assessment
GitHub, acting as the CVE Numbering Authority (CNA) for this issue, assigned a CVSS 4.0 base score of 7.6, reflecting a high severity rating due to the potential for unauthorized privileged access without user interaction. In contrast, the National Vulnerability Database (NVD) lists the same vulnerability under CVSS 3.1 with a base score of 6.8, rating it medium. The NVD record includes the weaknesses CWE‑287 (Improper Authentication) and CWE‑346 (Origin Validation Error). The discrepancy arises from differing interpretations of attack requirements and impact metrics between the two scoring systems.

Relation to a Recent Enterprise‑Only Flaw
Approximately two weeks prior to the June 24 patch for CVE‑2026-59208, n8n addressed another Enterprise‑only vulnerability tracked as CVE‑2026-54305. That flaw allowed any authenticated user to overwrite or revoke another user’s stored OAuth tokens via the Dynamic Credentials endpoints, resulting from a missing ownership check. While both issues reside in the Enterprise tier and involve insufficient validation, they are distinct: CVE‑2026-54305 concerns authorization logic for credential management, whereas CVE‑2026-59208 concerns identity binding during token exchange.

Patch Details and Affected Versions
The corrective changes first appeared in n8n releases 2.27.4 and 2.28.1. All versions prior to 2.27.4 are vulnerable, as is the specific version 2.28.0 (which lacked the fix). The patch modifies the token‑exchange lookup routine to require a match on both the iss and sub claims, thereby restoring the intended unique identification of users. As of July 16, the npm package’s latest and stable tags both point to 2.30.6, indicating that users who regularly follow the project’s weekly minor releases are already protected. Administrators should verify their current version and, if necessary, upgrade to the newest stable release supported by their environment.

Mitigation Recommendations
If immediate upgrading is infeasible, n8n advises two short‑term work‑arounds:

1. Reduce the trusted‑issuer list to a single key – By ensuring that only one external signer is trusted, the scenario where two issuers could emit identical sub values is eliminated.
2. Disable token exchange entirely – Turning off the preview feature removes the vulnerable code path altogether.

The advisory labels both measures as short‑term mitigations and notes that they do not fully remediate the underlying risk; the definitive solution remains applying the patched version.

Discovery, Disclosure, and Timeline
The vulnerability was initially identified by the Strix AI penetration‑testing agent, whose findings were submitted via the GitHub account bearsyankees. n8n acknowledged the report and issued the fix on June 24, 2026. The corresponding CVE record (CVE‑2026-59208) was not made public until July 9, 2026, after which the details appeared in public databases and news outlets. Despite the disclosure, no exploit code or widespread attacks have been reported as of the article’s date (July 16, 2026).

Conclusion
CVE‑2026-59208 highlights a subtle but critical logic error in n8n’s Enterprise token‑exchange flow: trusting the sub claim alone when multiple issuers are permitted allows an attacker to leapfrog authentication by presenting a legitimately signed token that shares a subject value with another user. The flaw is confined to a niche set of preview‑enabled, multi‑issuer Enterprise deployments, limiting its broad impact but still posing a high‑risk scenario for affected OEM partners. Promptly upgrading to version 2.27.4 or later—or, alternatively, restricting the trusted‑issuer list to a single key or disabling token exchange—effectively neutralizes the threat. The episode serves as a reminder that identity‑binding logic must always consider the full context of a token (issuer + subject) to prevent cross‑issuer impersonation.