CVE-2026-59208: n8n Cross-Issuer Token Exchange Authentication Bypass - What It Means for Your Business and How to Respond

Introduction

If your organization uses n8n to automate business processes, connect applications, or move sensitive information, CVE-2026-59208 deserves prompt attention. The vulnerability can allow an attacker to access another user’s n8n account in specific Enterprise configurations. That account may provide access to automated workflows, business data, integrations, and stored credentials.

You may be at risk if your n8n deployment uses the token exchange feature with more than one trusted external identity provider. Self-hosted Enterprise environments and eligible n8n Cloud Enterprise deployments should confirm their configuration and version status.

This post explains what CVE-2026-59208 means for your business, how to determine whether you are affected, what steps to take now, and how technical teams can verify and remediate the issue.

S1: Background & History

n8n published its security advisory and released fixes on June 24, 2026. The Canadian Centre for Cyber Security listed affected n8n releases before 1.123.61, before 2.27.4, and version 2.28.0. The corrected releases include 1.123.61, 2.27.4, and 2.28.1, depending on the release branch.

The issue was reported by the GitHub account bearsyankees, associated with Strix, an artificial intelligence penetration-testing agent. The public CVE record appeared on July 9, 2026. The National Vulnerability Database assigns CVE-2026-59208 a CVSS 4.0 score of 7.6, rated High. It identifies the issue as an origin validation error and improper authentication.

In plain language, n8n could confuse two identities from different trusted sources and grant access to the wrong local account.

S2: What This Means for Your Business

The primary business risk is unauthorized access to an n8n user account. If that account can view, edit, or execute workflows, an attacker may be able to alter business processes, redirect information, or use existing integrations in unintended ways.

Your exposure depends on what n8n does in your environment. Workflows may connect to customer relationship systems, payment platforms, cloud storage, messaging tools, databases, internal applications, or production services. They may also contain references to credentials and operational logic that reveal how your business functions.

The consequences can include interrupted automation, altered records, unauthorized data access, fraudulent activity, and costly investigation. A compromised workflow could silently change where reports are delivered, modify customer data, or trigger actions at the wrong time.

You may also face reputational damage if customers, partners, or employees learn that an automation platform was used to access sensitive information. Depending on your industry and contracts, the incident may create privacy, security, notification, or audit obligations in the United States or Canada. The vulnerability does not automatically mean that a breach occurred, but an affected deployment should be investigated rather than assumed safe.

S3: Real-World Examples

• Regional bank: An attacker reaches an n8n account used to manage reporting and customer-service workflows. The attacker could change destinations for exported reports, disrupt scheduled processes, or access information connected to financial operations.
• Healthcare provider: A compromised account has access to workflows that coordinate appointment data, staff notifications, and clinical system integrations. Unauthorized access could expose protected information and require a formal incident assessment.
• Mid-sized software company: The company embeds n8n inside its product and connects multiple customer identity systems to the platform. An identity mix-up could undermine confidence in tenant separation and allow activity to appear under the wrong customer or administrator.
• Regional manufacturer: An internal automation user manages supplier alerts, inventory updates, and cloud-storage transfers. An attacker who gains access could delay purchasing signals, alter operational records, or use connected credentials to reach other systems.

S4: Am I Affected?

• Yes: You run n8n Enterprise in a self-hosted environment or an eligible n8n Cloud Enterprise deployment.
• Yes: The n8n token exchange feature is enabled. For self-hosted deployments, check whether N8N_ENV_FEAT_TOKEN_EXCHANGE=true. n8n documents token exchange as an Enterprise preview feature.
• Yes: Your deployment trusts two or more external identity issuers for token exchange.
• Yes: Your version is earlier than 1.123.61, earlier than 2.27.4, or is 2.28.0. Confirm the correct version branch before declaring the system safe.
• No for this specific issue: Token exchange is disabled and the preview module is not loaded. However, an old n8n version may still contain other vulnerabilities.
• Uncertain: Your team cannot identify the trusted issuer configuration, active Enterprise features, or exact n8n version. Treat the deployment as requiring verification.

Key Takeaways

• CVE-2026-59208 can allow unauthorized access to the wrong n8n user account in multi-issuer Enterprise configurations.
• Your workflows, connected business systems, stored integration details, and operational data may be at risk.
• Upgrade to a fixed n8n release, with 2.27.4 or 2.28.1 as the relevant minimum for the documented 2.x branches.
• If immediate patching is impossible, reduce token exchange to one trusted issuer or disable the feature while preparing the upgrade.
• Review logs, sessions, workflows, and connected credentials if an affected deployment may have been accessed.

Call to Action

Do not let an identity-boundary weakness become an operational incident. IntegSec can assess your n8n deployment, validate authentication controls, test connected workflows, and identify broader paths to business impact. Contact IntegSec for a focused penetration test and practical cybersecurity risk reduction plan.

Technical Appendix

A: Technical Analysis

CVE-2026-59208 affects n8n’s Enterprise token exchange identity-resolution path when the feature is enabled and more than one trusted external issuer is configured. The root cause is subject-only account binding. Although n8n validates an incoming token against the relevant issuer and signing key, the vulnerable identity lookup uses the JSON Web Token sub claim without qualifying it with the iss issuer claim.

An attacker who obtains a valid token from one trusted issuer can therefore attempt to use a subject identifier that corresponds to a victim under another trusted issuer. Successful resolution can provide access to the victim’s n8n account, including its permissions and connected workflows. Strix describes the fix as qualifying the identity with the issuer before lookup and persistence.

The network-reachable attack has Low attack complexity, requires a valid token from a trusted issuer, needs no victim interaction, and has no availability impact. The CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. The NVD record lists CWE-346, Origin Validation Error, and CWE-287, Improper Authentication.

B: Detection & Verification

Technical teams should verify both the installed version and the authentication configuration. A version-only scan can produce misleading results because the vulnerability requires token exchange and multiple trusted issuers.

Configuration review should identify whether the feature and either flow are enabled without printing sensitive values:

Scanner coverage should match versions below the fixed releases and, where possible, inspect the trusted issuer configuration. Tenable identifies the condition as an n8n account takeover issue in plugin 330282. The GitHub advisory identifier is GHSA-mq3m-f8x3-579w.

Relevant audit events include n8n.audit.token-exchange.succeeded, n8n.audit.token-exchange.failed, n8n.audit.token-exchange.identity-linked, and n8n.audit.token-exchange.user-provisioned. Investigators should correlate issuer, subject, user, source address, endpoint, and time. Network review should focus on unexpected requests to /rest/auth/oauth/token or /rest/auth/embed, repeated exchange attempts, successful exchanges from unusual locations, and the same subject appearing across different issuers.

C: Mitigation & Remediation

1. Immediate (0-24h): Upgrade n8n to the latest supported release. At minimum, use 1.123.61 or later for the 1.x line, 2.27.4 or later for the 2.27 line, and 2.28.1 or later for the 2.28 line. The vendor patch should be the primary remediation. Preserve relevant logs and configuration evidence before restarting the service. If an upgrade cannot occur immediately, reduce the trusted token exchange configuration to one issuer or disable token exchange by removing access to the feature and setting N8N_ENV_FEAT_TOKEN_EXCHANGE to false. Restricting the affected endpoints at a reverse proxy can provide additional containment, but it is not a substitute for patching.
2. Short-term (1-7d): Confirm that every production instance, standby node, container image, package lockfile, and infrastructure template uses a fixed release. Review successful and failed token exchange events for unexpected issuer and subject combinations. If suspicious activity is identified, revoke active sessions and issued access tokens according to the deployment’s session-management process, then rotate credentials available to affected accounts. Validate that each trusted issuer has the intended audience, signing keys, permitted algorithms, and least-privilege roles. Test both legitimate and negative cases, including two issuers that produce the same subject value.
3. Long-term (ongoing): Add authentication-boundary tests to the software delivery process and require security review whenever an identity provider is added or removed. Maintain an inventory of n8n instances, Enterprise features, external issuers, service accounts, workflows, and connected credentials. Monitor token exchange activity centrally, keep n8n versions current, and include n8n in recurring penetration tests that assess authorization after authentication, not only password and signature validation.

D: Best Practices

• Bind external identities to the issuer and subject as a pair; never treat a subject identifier as globally unique across identity providers.
• Keep the number of trusted issuers as small as operationally possible, and remove inactive or unnecessary issuer configurations.
• Set an explicit expected audience for every trusted key source so tokens intended for another service cannot be exchanged.
• Use least-privilege roles for token exchange and avoid granting administrative permissions to embedded integrations without a documented need.
• Monitor successful identity links, new user provisioning, role changes, and token exchange failures for unusual issuer, subject, location, or timing patterns.