n8n Token Exchange Issuer Authentication Bypass Vulnerability
n8n is an open source workflow automation platform. Prior to 2.27.4 and from 2.28.0 prior to 2.28.1, n8n instances configured with more than one trusted token-exchange issuer resolved external identities to local accounts using only the JWT sub claim and ignored the iss claim, allowing an attacker with a valid token from one trusted issuer and a sub matching a victim under another issuer to authenticate as that victim. This issue is fixed in versions 2.27.4 and 2.28.1.
Quick answer
n8n should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.
Who is affected
Affected versions
- Before 2.27.4
- 2.28.0 before 2.28.1
Fixed versions
- 2.27.4
- 2.28.1
How to fix it
n8n is affected by a token-exchange account binding flaw when more than one trusted issuer is configured. Upgrade to n8n 2.27.4, 2.28.1, or a later fixed release, then review identity provider mappings for same-subject cross-issuer collisions. Because n8n often holds workflow credentials, rotate secrets if unauthorized access is suspected.
- Inventory all self-hosted n8n instances and identify deployments using token exchange or multiple trusted issuers.
- Upgrade affected n8n branches to 2.27.4, 2.28.1, or a later vendor-supported fixed release.
- Review identity-provider configuration and ensure account binding includes both issuer and subject, not subject alone.
- Temporarily disable extra trusted token-exchange issuers if patching cannot be completed immediately.
- Audit user sessions, SSO login history, workflow access, project membership, and credential access for cross-issuer abuse.
- Rotate n8n API keys, workflow credentials, OAuth tokens, webhook secrets, and model or SaaS provider keys if account takeover is suspected.
- Harden n8n behind SSO, VPN or trusted reverse proxy rules and least-privilege workspace roles.
Scan now. Google sign-in is only needed to unlock fix guidance.
Verify the fix
- Confirm the running n8n version is 2.27.4, 2.28.1, or later on the affected branch.
- Validate a token from one trusted issuer cannot authenticate as an account registered under another issuer.
- Review login, workflow, credential, and project audit logs for suspicious cross-issuer access.
- Test normal SSO and token-exchange login after patching and configuration review.
- Run a Fixnx scan and confirm no public n8n admin or API route is exposed unexpectedly.
Related categories
Trusted references
FAQ
What is affected by CVE-2026-59208?
n8n versions listed as affected should be reviewed: Before 2.27.4, 2.28.0 before 2.28.1.
What should I fix first?
Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.
How do I confirm the fix worked?
Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.
Why can this risk appear in multiple categories?
A vulnerability can belong to more than one platform or ecosystem. Fixnx keeps one canonical risk page while also listing it in every relevant category.