n8n Token Exchange Flaw Could Let Attackers Log In as Users From Another Issuer
A vulnerability in n8n’s Enterprise token exchange feature allows attackers to log in as users from another issuer if the platform trusts more than one external token issuer. The flaw stems from a mismatch between the issuer and subject claims in the JWT, leading to a single n8n account being impersonated. The vulnerability was patched in version 2.27.4 and 2.28.1, and is currently affecting versions below 2.27.4 and 2.28.0. While the fix is in place, the advisory doesn't fully detail how an attacker obtains the vulnerable token.
A vulnerability in n8n’s Enterprise token exchange feature allows attackers to log in as users from another issuer if the platform trusts more than one external token issuer. The flaw stems from a mismatch between the issuer and subject claims in the JWT, leading to a single n8n account being impersonated. The vulnerability was patched in version 2.27.4 and 2.28.1, and is currently affecting versions below 2.27.4 and 2.28.0. The token exchange feature is designed to allow OEM partners to embed the product, an RFC 8693 implementation, and spare their users a second login screen. It involves a short-lived JWT signed by the partner, which n8n verifies against a configured public key, matching claims to a local account, and allowing the user to access the platform. However, the issue arises because the subject string (iss + sub) is only guaranteed to be unique within the issuer that minted it. If two issuers emit the same subject string, both land on the same n8n account.
The vulnerability is tracked as CVE-2026-59208, assigned a CVSS score of 7.6 (High) on CVSS 4.0 by GitHub, and 6.8 on CVSS 3.1. The NVD also lists the bug with CWE-287 and CWE-346. CISA’s July 13 SSVC assessment records exploitation as none, and The Hacker News found no public proof-of-concept in searches on July 16. The advisory states that the fix first landed in 2.27.4 and 2.28.1, and that versions below 2.27.4 and 2.28.0 are affected. N8n ships a new minor most weeks, so users should check the tag and take the newest stable build their deployment supports.
If patching is not immediately possible, users can mitigate the risk by either reducing the number of trusted issuers or disabling the token exchange feature. The advisory notes that disabling token exchange is not a full remediation, as it doesn't address how an attacker obtains the vulnerable token. The changelogs for 2.27.4 and 2.28.1 only mention a Python import fix, a Google Ads node upgrade, an AI workflow check, and a node-building change – not the identity binding issue. The vulnerability is described as a missing ownership check, not an identity binding, as highlighted in a separate advisory from June 10. N8n credits the report to GitHub’s bearsyankees account, who pointed out the issue within the token-exchange flow.