CVE-2026-59208: n8n: Cross-Issuer Token Exchange Account Binding via Subject-Only Identity Resolution

In token exchange, n8n verifies a JWT from a trusted external issuer and then finds the local account for that identity. When several issuers are trusted, the lookup used sub alone. Two issuers that emit the same subject value therefore resolve to the same n8n user.

The attacker needs a way to obtain a valid token from one trusted issuer, for example by holding an account there, with a sub equal to the victim's subject under a different issuer. They present it to n8n and are authenticated as the victim, with that user's workflows, credentials and permissions. If the victim is an owner or admin, the whole instance is at risk.

The attacker does not need to break any signature or steal a token. The token is genuine. The flaw is that n8n trusts the subject without tying it to the issuer. Subject values like short numeric IDs or email-style names collide easily across systems.

The flaw requires the token exchange feature to be on and more than one trusted external issuer to be configured. Single-issuer setups are not affected. The advisory rates confidentiality and integrity high.

The n8n npm package before 2.27.4, and 2.28.0 before 2.28.1, but only on instances where the token exchange feature is enabled and more than one trusted external issuer is configured.

npm ls n8n

For Docker, check the image tag. Then review your token exchange configuration and count the trusted issuers.

Upgrade to n8n 2.28.1 or later. The advisory text names 2.28.1 as the fix, while the package data also lists 2.27.4 as patched for the 2.27 line.

npm install [email protected]

Short-term mitigations, which do not fully fix the risk:

• If you do not need several issuers, trust only one.
• Disable token exchange if you do not use it.

Review n8n logins that came through token exchange. Look for sessions where the issuer is different from the one the user originally registered through, or where one local account is used with tokens from two issuers. Check the issuers' own logs for tokens minted for subjects that belong to other people. Unexpected activity in an account that was just accessed this way is a sign.

Impact

When an n8n instance is configured with more than one trusted token-exchange issuer, external identities are resolved to local accounts using only the JWT sub claim, ignoring the issuer (iss). As a result, two different issuers that emit the same subject value map to the same local account.

An attacker who can obtain a valid token from one trusted issuer with a sub matching a victim registered under a different issuer can authenticate as that victim and access their account.

This issue only affects instances where the token exchange feature is enabled and more than one trusted external issuer is configured.

Patches

The issue has been fixed in n8n version 2.28.1. Users should upgrade to this version or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• If multiple trusted issuers are not required, reduce the token exchange configuration to a single trusted issuer.
• Disable the token exchange feature entirely if it is not in active use.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.