# n8n Token Exchange Vulnerability Lets Attackers Impersonate Users Across Trusted Issuers


## The Threat


n8n, the open-source workflow automation platform widely adopted for enterprise integration and OEM deployments, shipped a critical authentication flaw that allowed attackers to log in as arbitrary users on affected instances. The vulnerability stems from incomplete token validation in n8n's Enterprise token exchange feature, which is designed to streamline single sign-on for embedded OEM deployments.


The root cause is elegant in its simplicity: n8n's token exchange implementation matched incoming JSON Web Tokens (JWTs) to local user accounts using only the sub (subject) claim while ignoring the iss (issuer) claim. According to JWT best practices defined in RFC 7519, a subject identifier is only guaranteed to be unique within the context of a single issuer. The full identity tuple is the pair: iss + sub. By keying user lookups on half that pair, n8n created a scenario where a valid JWT from issuer A carrying a subject string that existed under issuer B would incorrectly authenticate the user from issuer B.


In practice, this meant an attacker with a valid token from one trusted external identity provider could use it to impersonate any user at another trusted provider, bypassing password verification entirely. The vulnerability only manifests on Enterprise instances configured to trust two or more external token issuers, but for OEM partners embedding n8n into multi-tenant environments, this is a supported and potentially common configuration.


## Severity and Impact


| Attribute | Details |

|---|---|

| CVE ID | CVE-2026-59208 |

| CVSS Score (4.0) | 7.6 (High) |

| CVSS Score (3.1) | 6.8 (Medium) |

| CWE Identifiers | CWE-287 (Improper Authentication), CWE-346 (Origin Validation Error) |

| Attack Vector | Network |

| Attack Complexity | High |

| Privileges Required | None |

| User Interaction | None |

| Scope | Changed |

| Confidentiality Impact | High |

| Integrity Impact | High |

| Availability Impact | None |


The vulnerability requires an attacker to obtain a valid JWT from one of the trusted issuers, which is why attack complexity is rated as high. However, the specific threat model—whether ordinary users at a trusted issuer can influence the sub claim they receive—remains underspecified in public disclosures. The advisory notes only that tokens "can be obtained" without detailing the practical attack chain.


As of July 16, 2026, the CISA SSVC assessment rated exploitation likelihood as "none observed," and no public proof-of-concept has surfaced. However, the window between the June 24 fix and the July 9 public CVE disclosure suggests a responsible disclosure timeline that may have delayed research publication.


## Affected Products


n8n Self-Hosted & Cloud:

  • Versions below 2.27.4
  • Version 2.28.0 (specific breaking version)
  • Fixed in: 2.27.4, 2.28.1, and all subsequent releases

    • As of July 16, 2026, the latest stable version available on npm was 2.30.6. n8n releases a new minor version most weeks according to its release cadence, so deployments should patch to the latest stable build compatible with their infrastructure.


    Scope Clarification:

  • Enterprise instances only — this is not an open-source community edition vulnerability
  • Token exchange feature must be enabled — controlled by a separate preview flag
  • Requires two or more trusted external issuers — single-issuer configurations are unaffected

    • ## Mitigations


    Immediate Actions (if patching is delayed):


    1. Audit your configuration: Check whether token exchange is enabled and how many external issuers are configured in N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. If you're using token exchange with two or more trusted issuers, you are at risk.


    2. Reduce issuer scope: If operational continuity requires delay, temporarily reduce the trusted issuer list to a single provider. This eliminates the collision risk entirely while you plan patching.


    3. Disable token exchange: If the feature is not actively in use, disable it by toggling the preview flag off. This removes the attack surface without requiring a version bump.


    4. Patch to 2.27.4, 2.28.1, or later: The permanent fix is a version upgrade. n8n's deployment documentation provides upgrade paths for both self-hosted and cloud instances. Verify the release notes and test in a staging environment before applying to production.


    Long-Term Recommendations:


  • Review all authentication flows in your n8n instance and audit recent login activity for anomalies, particularly logins from unexpected geographic regions or at unusual times.
  • If you are an OEM partner embedding n8n, notify your customers of this vulnerability and the patching timeline immediately.
  • Consider implementing additional identity verification layers (e.g., step-up authentication or IP whitelisting) for high-privilege users and administrative functions.
  • Track n8n's release cycle and maintain a patch schedule that closes security gaps within 30 days.

    • ## References


  • CVE-2026-59208: https://nvd.nist.gov/vuln/detail/CVE-2026-59208
  • n8n Release Notes: https://github.com/n8n-io/n8n/releases/tag/n8n@2.27.4
  • n8n Deployment Docs: https://docs.n8n.io/
  • RFC 7519 (JSON Web Token): https://tools.ietf.org/html/rfc7519
  • RFC 8693 (OAuth 2.0 Token Exchange): https://tools.ietf.org/html/rfc8693
  • Reporter (Strix): https://github.com/bearsyankees

    • ---


    ## HackWire Analysis


    This vulnerability is a textbook example of identity-binding failures that plague multi-tenant authentication systems. The bug itself is simple—validate the full identity tuple, not half of it—yet it's emblematic of a broader pattern: authentication features bolt on without the rigor they demand.


    What makes CVE-2026-59208 particularly notable is the Enterprise-only scope masking what could be wide-ranging customer impact. n8n's OEM model means a single vulnerable instance could protect dozens of downstream customers, each of whom embedded n8n into their own products. A flaw in n8n's token exchange becomes a flaw in their customers' identity systems. The advisory's focus on "Enterprise and token exchange must be enabled" sounds reassuring until you realize that OEM partners often run large fleets of instances with exactly this configuration.


    The timing is also worth noting. The fix shipped June 24, but the CVE didn't go public until July 9—a 15-day delay. This is responsible disclosure, but it means organizations relying on CVE feeds (rather than direct vendor channels) had no visibility into a critical authentication flaw for two weeks. Organizations that patch only on CVE publication, not vendor releases, are at higher risk of missing these windows.


    The underspecified threat model is a gap worth highlighting. The advisory says attackers can "obtain" a valid token from a trusted issuer but doesn't detail whether this requires compromising an issuer's signing key, intercepting a legitimate user's token, or manipulating a user's sub claim at issuance time. Each scenario carries wildly different blast radius implications. Until this is clarified, OEM partners should assume the worst-case scenario and prioritize patching accordingly.


    Finally, this is the second Enterprise-only identity-related flaw in n8n in as many months. In late May, CVE-2026-54305 exposed OAuth token management to unauthorized overwrite/revocation through a missing ownership check. Sequential flaws in adjacent security surfaces suggest the codebase could benefit from a dedicated identity security review rather than reactive patching alone.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)