n8n cross-issuer JWT bypass logs attackers in as anyone

The workflow-automation platform n8n disclosed a token-exchange flaw on 2026-07-09, tracked as CVE-2026-59208, that let a JWT minted by one trusted issuer log the bearer in as a user belonging to a different trusted issuer. The Hacker News walked through the finding on 2026-07-16; the fix landed in n8n 2.27.4 and 2.28.1 on 2026-06-24, roughly two weeks before the advisory published.

The bug lives in a narrow slice of the product — Enterprise deployments that have been configured to trust more than one external identity provider via N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. On a single-issuer setup, or an install with token exchange disabled, none of this reaches you. That is a real constraint, not a face-saving one; most n8n users are in one of those two buckets and can move on. What follows is for anybody running the OEM or Enterprise SSO path with two or more IdPs wired in.

The mistake is a familiar one: n8n matched the incoming JWT to a local user account on the sub claim alone, and ignored iss. The researcher’s write-up puts the shape of it plainly — a sub value is only unique inside the issuer that minted it, so identity in a multi-issuer world has to be the pair (iss, sub), not sub on its own. Once you drop the issuer from the check, a valid token from Issuer A carrying a sub that happens to belong to a user under Issuer B lets you log in as that user. The password never enters into it. The MFA never enters into it. The audit trail sees a normal, well-formed token exchange.

Whether this is trivially weaponizable in a given environment depends on a question the advisory declines to answer: can users at any of the trusted issuers pick or influence the sub claim that provider mints for them? At most enterprise IdPs the sub is a stable, opaque, provider-assigned string, and the attack becomes a matter of guessing values that other IdPs have handed out to real accounts — plausible against small numeric or username-based IDs, hard against GUIDs. At consumer or self-service IdPs, or ones where a customer can register an arbitrary external ID, the picture is different, and the ceiling for who you can impersonate rises to whoever the operator ever provisioned. Both cases sit inside the same CVE.

CVSS gave this two scores. GitHub’s advisory records a CVSS 4.0 of 7.6 (high). NVD’s CVSS 3.1 sits at 6.8 (medium). CWE-287 and CWE-346. As of the CISA SSVC assessment recorded on 2026-07-13, no public exploitation and no PoC — which is the current state of the world, not a promise about next week.

What to do about it is short. Upgrade to 2.27.4, 2.28.1, or a later release — current stable on npm is 2.30.6. If you can’t take the update immediately, the advisory allows two interim measures: cut the trusted-issuer list back to one via N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, or disable token exchange entirely. n8n is explicit that both are incomplete mitigations. Neither closes the underlying identity-composition mistake; both reduce the blast radius while you schedule the real fix. Neither release note for 2.27.4 or 2.28.1 mentions the security content — the advisory is the only place the fix is documented as a fix.

A last note on where this fits. Multi-issuer identity is the direction most enterprise SaaS has been walking for a decade, and every product that adds it eventually has to answer the question n8n answered the wrong way in an earlier release: what makes two tokens equivalent? Sub-only comparison is the same kind of shortcut that produced OAuth client-ID spoofing in Entra sign-in logs earlier this month and the SharePoint JWT auth-bypass Rapid7 wrote up on Monday — different products, different endpoints, same underlying habit of treating a piece of a token as if it stood for the whole. It is not the last time this vuln class will show up on a KEV-adjacent write-up this year.