n8n's JWT Login Bug Let the Wrong Issuer Vouch for the Wrong User

n8n has patched a vulnerability in its Enterprise token exchange feature that could allow an attacker holding a valid JWT from one trusted issuer to authenticate as a completely different user registered under a different issuer. No password required.

The bug, tracked as CVE-2026-59208, was quietly fixed on June 24 and the CVE record surfaced publicly on July 9. Credit goes to GitHub user bearsyankees, linked to Strix, a company building an AI penetration testing agent. Strix says their agent found the flaw while probing n8n's token exchange flow.

The Actual Problem

n8n's token exchange feature is an RFC 8693 implementation aimed at OEM partners who embed n8n in their own products. The idea is to let their users authenticate without a separate login prompt. The partner signs a short-lived JWT with their private key, n8n validates it against a pre-configured public key stored in N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, and maps the token's claims to a local user account.

The mapping is where things went wrong. n8n matched incoming tokens to local accounts using only the sub (subject) claim. It ignored iss (issuer) entirely.

This matters because RFC 7519 is quite clear that a sub value is only guaranteed to be unique within the context of the issuer that produced it. The proper unique identifier for a user is the combination of both: iss plus sub together. Two different issuers are entirely free to issue tokens sharing the same subject string. n8n only checked half the pair. If two configured issuers happened to use the same sub value for different users, both tokens landed on the same n8n account.

How Exposed Are You?

The attack only applies if token exchange is enabled and the deployment trusts at least two external issuers simultaneously. Token exchange is Enterprise-only and still flagged as a preview feature, so this is a narrow surface: OEM deployments specifically, where trusting multiple issuers is a deliberately supported configuration.

What the advisory does not spell out is how an attacker would reliably obtain a token carrying a specific sub value. That depends on whether ordinary users at a trusted issuer can influence what subject identifier they receive, and the public record gives no clear answer. GitHub's CVSS 4.0 scoring notes that attack requirements exist but doesn't elaborate.

GitHub, acting as CNA, rates this 7.6 on CVSS 4.0, putting it in the high band. NVD scores it lower at 6.8 on CVSS 3.1 and hasn't produced a 4.0 assessment at all. CISA's July 13 SSVC evaluation recorded zero known exploitation. No public proof-of-concept had appeared as of mid-July.

Two weeks before this fix, n8n patched a separate Enterprise-only issue, CVE-2026-54305, where any authenticated user could overwrite or revoke another user's stored OAuth tokens through the Dynamic Credentials endpoints. A different class of bug, missing an ownership check rather than mangling identity binding, but the same general territory.

Patching and Workarounds

CVE-2026-59208 affects all n8n releases below 2.27.4 and 2.28.0. The fix landed in 2.27.4 and 2.28.1. As of July 16, n8n's npm package was already on 2.30.6. The project ships new minors frequently, so checking the current stable tag and upgrading is straightforward for most deployments.

If an immediate patch isn't possible, the short-term options are: reduce N8N_TOKEN_EXCHANGE_TRUSTED_KEYS to a single issuer, or disable the token exchange feature entirely via its preview flag. n8n's advisory notes these as mitigations rather than full remediations, though by their own scope statement an instance with the feature off is not affected. The wording appears copy-pasted from at least three other n8n advisories, so treat it accordingly.

One final thing worth flagging: neither the 2.27.4 nor the 2.28.1 changelogs mention this fix at all. Between them they document a Python import correction, a Google Ads node update, and an AI workflow check. Nothing about identity. If your upgrade process runs on changelogs, this one would have slipped straight past you. The advisory is the only place it's documented.