n8n, a popular workflow automation platform, has addressed a critical security vulnerability, CVE-2026-59208, that allowed attackers to log in as other users by exploiting its token exchange authentication mechanism. This flaw could grant unauthorized access to sensitive enterprise data and system configurations.
The vulnerability, patched on June 24, 2026, specifically impacted enterprise instances configured with multiple external token issuers. It enabled a scenario where a valid token from one issuer, containing a subject identifier (sub) belonging to a user under a different issuer, could falsely authenticate the holder as that user, bypassing password checks entirely. The affected fix was released in versions 2.27.4 and 2.28.1 of the platform.
Understanding CVE-2026-54305 and its Implications for n8n Security
The vulnerability, officially cataloged as CVE-2026-59208, was publicly disclosed on July 9, 2026, following a report from GitHub user bearsyankees, associated with Strix, a company developing an AI penetration testing agent. Strix indicated that their agent identified the identity-binding bug within n8n’s token exchange flow.
Token exchange in n8n’s enterprise offerings serves as an implementation of RFC 8693, designed for OEM partners to embed the platform without requiring their users to undergo a secondary login process. The partner generates a short-lived JSON Web Token (JWT) signed with their private key. n8n then verifies this token against a pre-configured public key, matches its claims to a local user account, and grants access. The trusted keys are managed under the N8N_TOKEN_EXCHANGE_TRUSTED_KEYS setting, and at the time of the vulnerability, this feature was still marked as a preview in the deployment documentation.
While the JWT itself might be valid, the core of the issue lay in how n8n matched incoming tokens to local accounts. According to RFC 7519, a subject identifier (sub) is intended to be unique within the context of its issuer. The combination of the issuer (iss) and the subject (sub) typically forms a globally unique identifier for a user. However, n8n’s implementation incorrectly relied solely on the sub claim for matching, neglecting the iss claim. This oversight meant that if two different issuers generated tokens with identical sub values, n8n would associate both with the same local account, creating an authentication bypass.
Assessing the Scope and Severity of the n8n Vulnerability
The practical impact of CVE-2026-59208 is confined to n8n instances where the token exchange feature is enabled and actively configured to trust more than one external token issuer. n8n has stated that other functionalities of the platform are unaffected. Crucially, the token exchange feature is exclusive to n8n’s enterprise tier and was still in a preview stage, suggesting that the number of exposed deployments is relatively limited. These are primarily OEM integrations where the configuration of multiple trusted issuers is a supported, albeit advanced, setup.
The exact method by which an attacker could obtain a malicious token remains unspecified in the public advisory. A key unanswered question is the extent to which an ordinary user within a trusted issuer’s environment can influence the sub claim in the tokens they receive. The CVSS 4.0 vector assigned by GitHub notes the presence of attack requirements but does not elaborate further.
GitHub, acting as the CVE Numbering Authority (CNA), has assigned CVE-2026-59208 a CVSS 4.0 score of 7.6, categorizing it as high. In contrast, the National Vulnerability Database (NVD) has assessed the same vulnerability using CVSS 3.1, resulting in a medium severity rating of 6.8, and has not yet provided a CVSS 4.0 assessment. The NVD record also includes CWE identifiers CWE-287 (Improper Authentication) and CWE-346 (Origin Validation Error). The Cybersecurity and Infrastructure Security Agency (CISA) evaluated the exploitation status on July 13, 2026, as none reported. Searches conducted by The Hacker News on July 16, 2026, did not reveal any publicly available proof-of-concept exploits for this security flaw.
It is noteworthy that two weeks prior to the fix for CVE-2026-59208, n8n patched another enterprise-only vulnerability, CVE-2026-54305. This earlier flaw allowed any authenticated user to alter or revoke stored OAuth tokens via the Dynamic Credentials endpoints due to a missing ownership check. While a different type of vulnerability, it affected the same authentication surface.
The Hacker News has reached out to n8n for further details regarding the scope and impact of CVE-2026-59208. This article will be updated upon receiving a response.
Mitigation Strategies for CVE-2026-54305 and n8n Updates
The security risk of CVE-2026-59208 affects all n8n releases prior to version 2.27.4 and version 2.28.0. The patches were introduced in version 2.27.4 and 2.28.1. As of July 16, 2026, n8n’s npm package listed version 2.30.6 under both its latest and stable tags. Based on n8n’s release cadence, which typically introduces a new minor version weekly, users should aim to deploy the newest stable build their infrastructure supports.
For organizations unable to immediately apply the patches, interim mitigation steps include reconfiguring the token exchange setup. This involves reducing the list of trusted issuers to a single entry within the N8N_TOKEN_EXCHANGE_TRUSTED_KEYS configuration, or alternatively, disabling the token exchange feature altogether via its preview flag. n8n’s advisory characterizes these as short-term measures that do not fully resolve the underlying vulnerability.
However, according to n8n’s own scope statement, instances with the token exchange feature switched off are not exposed to this specific threat. Interestingly, neither the release notes for the patched versions nor the advisory for CVE-2026-59208 explicitly mention the security fix. The changelogs for versions 2.27.4 and 2.28.1 detail updates such as a Python import fix, an upgrade to the Google Ads node, an AI workflow check, and a node-building enhancement, but provide no information regarding the authentication bypass. This oversight means that teams relying solely on changelogs for upgrade decisions might overlook critical security patches like this one.