Security researchers at Strix AI discovered a critical authentication bypass in n8n, the popular workflow automation platform with nearly 200,000 GitHub stars and over 100 million Docker pulls. The vulnerability, tracked as CVE-2026-59208 (CVSS High), allows attackers to take over user accounts by exploiting a flaw in n8n's token exchange implementation.

Vulnerability Details

CVE ID: CVE-2026-59208
CVSS Score: High (7.5)
Affected Versions: n8n < 2.28.1 and < 2.27.4
Fixed Versions: n8n 2.28.1 and 2.27.4
Component: Token Exchange authentication flow
Attack Vector: Network, no user interaction required
Impact: Cross-issuer account takeover — workflows, credentials, and data access

Impact Assessment

The vulnerability affects n8n instances that configure multiple trusted identity providers for token exchange authentication. When an organization uses more than one trusted issuer (e.g., Auth0 for employees, Okta for contractors, or multiple Azure AD tenants), an attacker with a valid token from one issuer can impersonate any user who shares the same sub (subject) claim value at another trusted issuer.

What's at risk:

• Complete account takeover of any user registered under a different trusted issuer
• Access to all workflows, credentials, and secrets stored in the compromised account
• Ability to execute arbitrary workflows with the victim's permissions
• Potential lateral movement through connected integrations (databases, APIs, cloud services)

The blast radius is significant because n8n often serves as a central automation hub with credentials for databases, cloud providers, payment systems, and internal APIs.

Affected Systems

You are vulnerable if:

• n8n version is below 2.28.1 (2.28.x branch) or 2.27.4 (2.27.x branch)
• Token exchange authentication is enabled (N8N_TOKEN_EXCHANGE_ENABLED=true)
• Two or more trusted issuers are configured in the token exchange settings

You are NOT vulnerable if:

• You use only a single trusted issuer for token exchange
• Token exchange is disabled (default in many self-hosted deployments)
• You use n8n's built-in email/password, LDAP, or SAML authentication without token exchange

Cloud-hosted n8n customers should verify with n8n support whether their instance was patched automatically.

Mitigation & Patching

Immediate Action Required

1. Upgrade n8n immediately to version 2.28.1 or 2.27.4:

   bash

2. If you cannot upgrade immediately, reduce trusted issuers to exactly one:

   json

3. Disable token exchange entirely as a last resort:

   bash

The Root Cause (Technical Deep Dive)

The bug exists in the gap between token verification and identity resolution — two separate functions that each look correct in isolation.

Token verification (TokenExchangeService.verifyToken()) correctly validates:

• Key ID (kid) matches a trusted key
• Issuer (iss) matches a configured trusted issuer
• Audience (aud) matches expected value
• Algorithm is in the allowed list

Identity resolution (IdentityResolutionService.resolve()) then maps that verified token to a local user account using ONLY:

The AuthIdentity entity has a unique constraint on (providerId, providerType) only — issuer is logged but not part of the uniqueness constraint.

This means:

1. User Alice authenticates via Issuer A (corporate IdP) with sub: "[email protected]"
2. n8n creates local account linked to providerId: "[email protected]", providerType: "token-exchange"
3. Attacker obtains valid token from Issuer B (partner IdP) with same sub: "[email protected]"
4. n8n verifies token against Issuer B's keys — valid!
5. Identity resolution looks up providerId: "[email protected]" — finds Alice's account!
6. Attacker gains full access to Alice's n8n account

Both tokens are cryptographically valid. The bug is that n8n "throws away iss, keeps sub, and collapses two issuers onto one local identity."

The Fix

n8n's patch qualifies the provider ID with a hash of the issuer:

This change affects:

• Identity lookup during token exchange
• Account linking when users connect external identities
• Just-in-time (JIT) user provisioning
• Database unique constraint on AuthIdentity (migration included)

Detection

Check Your Configuration

Look for trustedIssuers array length > 1.

Audit Logs for Suspicious Activity

Check n8n authentication logs for:

• Same sub value authenticating from different iss values
• Rapid successive logins from different geographic locations
• Token exchange authentication failures followed by successes

GitHub Security Advisory

Monitor the official advisory: GHSA-mq3m-f8x3-579w

Frequently Asked Questions

Q: Does this affect n8n Cloud (hosted) users?
A: n8n Cloud instances were patched automatically. Contact n8n support for your specific instance status.

Q: Can this be exploited without a valid token from a trusted issuer?
A: No. The attacker needs a valid, correctly signed JWT from a trusted issuer. The vulnerability is in how n8n maps that valid token to a local account, not in token validation itself.

Q: What if I use only one identity provider?
A: You are not vulnerable. The collision requires at least two trusted issuers configured simultaneously.

Q: Does the fix require a database migration?
A: Yes. The AuthIdentity table schema changes to include issuer in the unique constraint. The migration runs automatically on upgrade.

Q: Can I work around this without upgrading?
A: Reduce trusted issuers to exactly one, or disable token exchange entirely (N8N_TOKEN_EXCHANGE_ENABLED=false).

Q: Are there any signs this was exploited in the wild?
A: As of publication, no public evidence of active exploitation exists. The vulnerability was discovered through automated security testing by Strix AI and reported responsibly.

Key Takeaways

1. Cross-issuer identity confusion is a real class of bugs — verification and binding must agree on what constitutes a unique identity
2. Token exchange with multiple IdPs needs issuer-scoped identity keys — sub alone is insufficient when multiple authorities can mint tokens
3. Static analysis misses cross-function logic gaps — each function (verify, resolve) looked correct independently; the bug was in the contract between them
4. Automated security testing finds what humans miss — Strix AI's agent-based approach discovered this by exploring the gap between verification and resolution
5. Upgrade n8n now if you use token exchange with multiple issuers — versions 2.28.1 and 2.27.4 contain the fix

---

Sources: Strix AI Blog • GitHub Security Advisory GHSA-mq3m-f8x3-579w • n8n Commit a4bc50f