Full Report
n8n, the workflow automation platform, handed out the wrong accounts at login. On Enterprise instances configured to trust more than one external token issuer, it matched an incoming JWT to a local user on the sub claim alone and ignored iss. A valid token from issuer A carrying a sub that belongs to someone under issuer B logged you in as them. Their password never
Analysis Summary
# Vulnerability: n8n Cross-Issuer Account Takeover via Token Exchange
## CVE Details
- **CVE ID:** CVE-2026-59208
- **CVSS Score:** 7.6 (High) per GitHub (CNA) / 6.8 (Medium) per NVD
- **CWE:** CWE-287 (Improper Authentication), CWE-346 (Origin Validation Error)
## Affected Systems
- **Products:** n8n Workflow Automation (Enterprise Edition)
- **Versions:**
- All versions below 2.27.4
- Version 2.28.0
- **Configurations:**
- Enterprise instances with the "Token Exchange" feature enabled.
- Instances configured to trust more than one external token issuer via `N8N_TOKEN_EXCHANGE_TRUSTED_KEYS`.
## Vulnerability Description
The flaw exists in n8n's implementation of the Token Exchange flow (RFC 8693), a feature used primarily by OEM partners to provide seamless logins. During the authentication process, n8n verifies the external JSON Web Token (JWT) correctly but fails to properly bind the identity to a specific issuer.
The system matches an incoming JWT to a local user account based solely on the `sub` (subject) claim, while ignoring the `iss` (issuer) claim. Because `sub` values are only guaranteed to be unique within the context of a single issuer, an attacker possessing a valid token from "Issuer A" with a specific `sub` ID can log in as a user from "Issuer B" if they share the same `sub` ID.
## Exploitation
- **Status:** No reports of exploitation in the wild at this time.
- **Complexity:** Medium (Requires valid token generation/access from a trusted issuer and knowledge of target `sub` IDs).
- **Attack Vector:** Network
- **PoC Availability:** None currently public. The flaw was discovered using an AI penetration testing agent by Strix.
## Impact
- **Confidentiality:** High (Full account takeover, access to sensitive workflows/credentials).
- **Integrity:** High (Ability to modify or delete automated workflows).
- **Availability:** Medium (Potential for service disruption through workflow modification).
## Remediation
### Patches
Update to one of the following versions or newer:
- **v2.27.4**
- **v2.28.1**
- **v2.30.6** (Current stable recommendation as of mid-July 2026)
### Workarounds
If patching is not immediately possible:
1. **Reduce Trusts:** Limit the `N8N_TOKEN_EXCHANGE_TRUSTED_KEYS` configuration to trust only a single external issuer.
2. **Disable Feature:** If not required for business operations, disable the Token Exchange preview flag entirely.
## Detection
- **Indicators of Compromise:** Unusual login activity where a user logs in via an issuer that does not typically manage that specific user ID.
- **Detection Methods:** Audit logs should be reviewed for discrepancies between the `iss` claim in the authentication token and the expected issuer for the associated user account.
## References
- **Vendor Advisory:** hxxps[://]github[.]com/n8n-io/n8n/security/advisories/GHSA-mq3m-f8x3-579w
- **NVD Entry:** hxxps[://]nvd[.]nist[.]gov/vuln/detail/CVE-2026-59208
- **Researcher Technical Blog:** hxxps[://]www[.]strix[.]ai/blog/n8n-cross-issuer-account-takeover
- **News Source:** hxxps[://]thehackernews[.]com/2026/07/n8n-token-exchange-flaw-could-let.html