n8n CVE-2026-59208: a JWT token exchange flaw that logs you in as someone else
> In short: CVE-2026-59208 is a JWT identity-binding flaw in n8n's Enterprise token-exchange flow. On instances configured to trust more than one external issuer, a valid token from issuer A carrying a sub that belongs to a user under issuer B logged you in as them. No password involved. Fix: n8n 2.27.4 and 2.28.1 (shipped June 24, 2026).
Why this matters to you
n8n is the open-source workflow automation platform a lot of SaaS teams embed for internal automation, customer integrations, or OEM features. We already wrote about n8n webhook security — this CVE sits on a different surface, but the same product, and it targets the most sensitive thing n8n holds: who you are logged in as.
More broadly, this is a JWT bug, and JWT bugs travel. The exact same identity-binding mistake shows up in custom SSO implementations, OEM embedded products, and any home-grown token-exchange flow. If you build federated identity, read on.
The flaw in two sentences
Token exchange (RFC 8693) is n8n's Enterprise route for OEM partners who embed the product. The partner signs a short-lived JWT with its own key, n8n verifies it against a configured public key (N8N_TOKEN_EXCHANGE_TRUSTED_KEYS), matches the claims to a local account, and the user is in.
The token itself checked out. The matching was the bug. n8n keyed on sub alone and ignored iss. A sub value is only guaranteed unique inside the issuer that minted it — per RFC 7519, identity is the *pair* iss + sub. n8n kept only half. Nothing stops two issuers from emitting the same subject string, and when they do, both land on one n8n account.
The lesson: identity is a pair, not a claim
This is the part worth memorizing, because it is not specific to n8n. Any time your backend resolves a JWT to a local user, the lookup key must be (iss, sub), never sub alone. The moment you trust two issuers — two identity providers, an OEM partner and your own IdP, a staging and a prod tenant — sub collisions become possible, and the first one to register a username wins every collision.
Classic real-world variants of this bug:
sub to a user row without scoping the lookup to the tenant.All the same bug, different dressing.
How big is the exposure
n8n's scope is narrow and they say so. Token exchange is Enterprise-only, still flagged as preview, and the flaw only bites instances that trust at least two external issuers. That is a small, specific set — mostly OEM deployments. CVSS lands at 7.6 on 4.0 (high) and 6.8 on 3.1 (medium), CWE-287 (improper authentication) and CWE-346 (origin validation error).
What the advisory does not pin down is how an attacker obtains the token. As of mid-July, CISA's SSVC assessment records no exploitation and there is no public proof-of-concept. The realistic question — can an ordinary user at a trusted issuer influence the sub they receive? — is not answered in the public record.
What to do
N8N_TOKEN_EXCHANGE_TRUSTED_KEYS to a single trusted issuer, or turn token exchange off entirely. The advisory calls both short-term measures but says neither fully remediates.iss. Add a test that mints two tokens with the same sub from two issuers and verifies they never resolve to the same account.For a SaaS vendor, the takeaway is the pair, not the platform: whenever identity crosses a trust boundary, iss + sub together, never one without the other.
Building HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
Zoom CVE-2026-53412: a critical account takeover in the Windows desktop client
An improper input validation flaw (CVSS 9.8) in Zoom Workplace for Windows, the VDI Client, and the Meeting SDK lets an unauthenticated attacker take over accounts via network access. Affects versions before 7.0.0. Fix available.
Authentication: JWT, OAuth, sessions — the flaws we see most
The most frequent implementation mistakes in JWT, OAuth 2.0, and classic sessions, with concrete examples and fixes.
Next.js CVE-2026-44578: an SSRF via WebSocket on self-hosted instances
An SSRF flaw (CVSS 8.6) in Next.js's built-in Node.js server lets an unauthenticated attacker proxy requests to your internal services. Vercel is unaffected; self-hosting is. Fix: 15.5.16 / 16.2.5.
Sources
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.