A vulnerability CVE-2026-59208 has been discovered in the n8n workflow automation platform that allows an attacker to authenticate as another user account without knowing the password. The issue affects Enterprise instances with the token exchange feature enabled and at least two trusted external JWT issuers. The system matched an incoming token to a local user solely by the value of the sub claim, ignoring iss — the token issuer. The patch was released on June 24 in versions 2.27.4 and 2.28.1; administrators of affected configurations need to update or reduce the number of trusted issuers to one.
Essence of the vulnerability: half an identifier instead of the whole
The token exchange function in n8n implements RFC 8693 and is intended for OEM partners embedding n8n into their products. A partner signs a short‑lived JWT with its own key, n8n verifies the signature against a preconfigured public key from the N8N_TOKEN_EXCHANGE_TRUSTED_KEYS environment variable, maps the claims to a local account, and lets the user in without re-authentication.
The problem lay in the matching logic. According to RFC 7519, the value of the sub claim is guaranteed to be unique only in the context of a specific issuer (iss). The correct user identifier is the pair iss + sub. However, n8n used only sub for binding, effectively relying on only half of the identifier.
The practical consequence: if two trusted issuers (A and B) issue tokens with the same sub value for different users, a valid token from issuer A allows authentication as the user registered under issuer B. The victim’s password is not involved at all — the system fully trusts the binding by sub.
Severity assessments and exploitation status
Severity assessments from different sources diverge. GitHub as the CNA has assigned the vulnerability a score of CVSS 4.0 — 7.6 (High). NVD rated it as 6.8 (Medium) under CVSS 3.1 and associated it with weakness classes CWE-287 (improper authentication) and CWE-346 (origin validation error). The discrepancy is explained both by differences between the CVSS 4.0 and 3.1 methodologies and by different interpretations of the attack conditions.
The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Based on available information, there are no public proofs of concept (PoC) and no confirmed exploitation cases.
Who is at risk
The impact surface is narrow, but the consequences are severe for affected configurations. The vulnerability manifests only when all three of the following conditions are met:
- n8n Enterprise license;
- the token exchange feature is enabled (according to the documentation, still in preview status);
- a configuration with two or more trusted external token issuers.
This is a typical scenario for OEM deployments where multiple partners integrate n8n into their platforms. For such instances, the vulnerability effectively enables cross-tenant account takeover — a user of one partner can gain access to the data and workflows of a user of another partner.
The question of practical exploitability remains open: the advisory does not clarify whether an ordinary user of a trusted issuer can influence the value of sub in their token. The CVSS vector from GitHub indicates that there are additional requirements for the attack but does not disclose them.
Context: the second Enterprise vulnerability in two weeks
Two weeks before releasing the patch for CVE-2026-59208, n8n developers fixed CVE-2026-54305 — another vulnerability limited to Enterprise functionality. It allowed any authenticated user to overwrite or revoke other users’ OAuth tokens via Dynamic Credentials endpoints due to the absence of a resource ownership check. Two different vulnerabilities — identity binding and resource access control — but both point to insufficient maturity of authorization checks in the platform’s Enterprise components.
Remediation recommendations
All n8n versions below 2.27.4, as well as version 2.28.0, are affected. The fix is available starting from versions 2.27.4 and 2.28.1.
- Updating is the top priority. Install at least version 2.27.4 or 2.28.1, and preferably the latest stable build.
- If an immediate update is not possible, reduce the list of trusted issuers in
N8N_TOKEN_EXCHANGE_TRUSTED_KEYSto a single one or completely disable the token exchange feature. According to n8n, instances with token exchange turned off are not vulnerable. - Review authentication logs for anomalous logins — sessions where a user authenticated via a token from one issuer but gained access to resources belonging to an account of another.
An important nuance: according to available information, the fix is not mentioned either in the changelog for version 2.27.4 or in the changelog for version 2.28.1. The information appears only in the advisory. Organizations that make update decisions solely based on release notes risk missing this patch.
Administrators of n8n Enterprise with token exchange enabled and multiple trusted issuers should treat updating as urgent. Even with the vulnerability’s limited scope, the impact of successful exploitation — full account takeover without any interaction with the victim — makes delay unjustified. Check your current version, the contents of N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, and decide whether to update or restrict the configuration.
