n8n Cross-Issuer Bug Turns JWT sub Into Account Takeover

Self-hosted n8n sits on a lot of secrets: API keys, OAuth tokens, internal webhooks, and workflows that act without a human in the loop. When authentication is wrong on that kind of system, the blast radius is not a single dashboard session. It is every integration the victim account can touch.

CVE-2026-59208 is a high-severity account-takeover bug in that exact path. Instances that enable token exchange with more than one trusted issuer bound external identities to local accounts using only the JWT sub claim and ignored iss. Two different IdPs that emit the same subject value collapse onto one local user. An attacker who holds a valid token from any trusted issuer, with a sub that matches a victim registered under another issuer, authenticates as that victim.

This is not a novel class of failure. It is the classic identity-federation mistake: treating sub as a global primary key instead of as a pair with the issuer. The good news is the precondition set is narrow. The bad news is that the people who hit it are exactly the ones wiring enterprise SSO into automation.

What actually broke

n8n’s token-exchange path accepts JWTs from configured external issuers and maps them onto local accounts. Per the advisory, when more than one issuer is trusted, that mapping used subject alone. Issuer was not part of the account key.

That violates how JWT identity is defined. RFC 7519 and OIDC both treat sub as unique within an issuer, not across issuers. Provider A’s sub=12345 and Provider B’s sub=12345 are different people. n8n treated them as the same person.

Impact is full authentication as the victim account: confidentiality and integrity of whatever that account can see and change. Availability is not in the CVSS impact. Severity is High (CVSS 4.0 base 7.6), with network attack vector, low complexity, privileges required low (attacker needs a legitimate token from one trusted issuer), and no user interaction. Attack requirements are marked present because the deployment must enable multi-issuer token exchange.

Affected versions: everything before 2.27.4, and the 2.28.0 line before 2.28.1. Fixed in 2.27.4 and 2.28.1. Problem types are CWE-287 (Improper Authentication) and CWE-346 (Origin Validation Error).

Who is actually exposed

Most single-IdP self-hosted installs are outside the blast radius. The bug only fires when all of the following are true:

• Token exchange is enabled
• More than one trusted external issuer is configured
• An attacker can obtain a valid token from at least one of those issuers
• That token’s sub collides with a victim’s sub under a different trusted issuer

That last condition is the real-world hinge. Numeric or sequential subjects from different IdPs can collide by accident. Shared email-style subjects, reused directory IDs after a migration, or copy-pasted test users make it worse. Even without a deliberate collision, an attacker who can mint or obtain tokens in one trusted IdP (compromised service account, overly broad OAuth client, staging IdP left in production trust) only needs a matching subject string.

If you only trust one issuer, or never turned on token exchange, this CVE does not apply. If you did multi-issuer federation for hybrid SSO (corporate IdP plus a partner, or Okta plus a secondary OIDC provider), you are in scope until you patch.

What to do on the host

Patch first. Upgrade to 2.27.4+ on the 2.27 line, or 2.28.1+ on 2.28. Confirm the running binary or container tag after deploy; n8n version drift between UI, API, and workers is easy to miss in multi-node setups.

If you cannot patch immediately:

• Drop the token-exchange config to a single trusted issuer
• Or disable token exchange entirely if nothing depends on it

Those are temporary mitigations. They shrink the attack surface but do not replace the fix. After upgrade, re-check that multi-issuer configs still work as expected; the correct binding is (iss, sub), so legitimate users from different issuers with identical subjects will no longer share a local account. That may surface as “missing” users or duplicate accounts that were previously collapsed by accident. Treat that as a data-cleanup task, not a regression.

Practical audit checklist for operators:

1. Inventory every trusted token-exchange issuer in config (env, config file, or UI, depending on how you deploy).
2. Confirm whether any two issuers can produce overlapping sub values (directory migrations, shared email claims, test fixtures).
3. Review which local n8n accounts were created or last authenticated via token exchange, and whether their linked identity includes issuer.
4. Rotate credentials reachable from high-privilege n8n accounts that may have been used under a collapsed identity.
5. Watch auth logs for successful logins where the issuer does not match the expected home IdP for that user.

If you front n8n with an external reverse proxy that already enforces a single IdP, that does not automatically fix this. The bug is inside n8n’s own multi-issuer resolution after a token is accepted.

Context: why n8n auth bugs keep mattering

n8n has taken a string of serious CVEs across RCE, credential handling, and access control. That pattern is not unique to this project; workflow engines concentrate privilege by design. They store OAuth tokens, call internal APIs, and run expressions and nodes with host-level reach. An account-takeover bug is therefore not “just SSO.” It is a shortcut into every secret the victim’s workflows hold.

CVE-2026-59208 is milder than unauthenticated RCE, and narrower than cross-tenant credential hijacks that hit enterprise features elsewhere in the same product family. Still, it is the kind of bug that survives code review because the happy path (one issuer, unique subjects) works fine. Multi-issuer is an edge configuration that enterprise self-hosters actually use, and subject-only binding is a well-documented anti-pattern in OIDC client libraries. The fix belongs in the identity key, not in documentation that says “please don’t reuse subjects.”

Production takeaway

Treat this as a configuration-gated high rather than a mass-internet emergency. Scan for multi-issuer token exchange. Patch to 2.27.4 or 2.28.1. If you must keep multiple issuers, verify that local account binding is now issuer-aware and that no two IdPs share subject namespaces you care about.

For teams designing auth around n8n or similar automation platforms: never key local users on sub alone when more than one issuer is trusted. Persist (iss, sub) (or a stable iss + sub composite) as the external identity. Anything less is an account-merge bug waiting for the second IdP.

Ship the upgrade. Then make the identity key match the standard.