n8n Token Exchange Flaw: How a Simple Bug Could Compromise User Accounts
In the world of enterprise software, trust is everything. But what happens when that trust is misplaced? That’s exactly what went wrong with n8n, the popular workflow automation platform, which recently patched a critical flaw in its token exchange feature. This vulnerability, tracked as CVE-2026-59208, could allow an attacker to log into the wrong user accounts under certain conditions.
What Went Wrong?
The issue lies in how n8n handles tokens from external issuers. In environments where n8n is configured to trust multiple issuers, the platform only checked the sub (subject) claim in the token to match it to a local user. The problem? It ignored the iss (issuer) claim, which is essential for ensuring the token is valid for the correct issuer.
Here’s the breakdown:
- If a token from Issuer A contained a sub value that matched a user under Issuer B, n8n would log the user into the wrong account.
- This means an attacker with a valid token from one issuer could potentially access someone else’s account if the sub values overlapped.
The fix was shipped on June 24, but the vulnerability wasn’t made public until July 9. Kudos to GitHub user bearsyankees (associated with Strix, an AI penetration testing company) for discovering and reporting the bug.
How Serious Is This?
The good news is that this flaw only affects n8n Enterprise instances with the token exchange feature enabled and configured to trust multiple issuers. Since token exchange is still marked as a preview feature, the number of affected deployments is likely small. However, for OEM partners embedding n8n into their products, this could have been a big deal.
The bad news? The public record doesn’t fully explain how an attacker might obtain a valid token or manipulate the sub value. The Common Vulnerability Scoring System (CVSS) rates this flaw as high (7.6), but the National Vulnerability Database (NVD) ranks it as medium (6.8). As of now, there’s no evidence of exploitation in the wild, but it’s still a wake-up call for anyone relying on n8n’s token exchange feature.
Patch or Disable: What You Need to Do
If you’re running an affected version of n8n (anything below 2.27.4 or 2.28.1), you’ll want to update ASAP. The fix is included in these versions and later. If patching isn’t an option right away, n8n recommends either disabling the token exchange feature or reducing the number of trusted issuers to just one.
Interestingly, neither the 2.27.4 nor the 2.28.1 release notes mention the fix. This highlights a common issue in enterprise software: critical security updates can fly under the radar if they’re not clearly communicated in changelogs.
Lessons Learned
This incident serves as a reminder of how small oversights can lead to big security risks. The n8n team deserves credit for addressing the issue promptly, but it also underscores the importance of thorough testing and clear documentation. For enterprises relying on n8n or similar tools, this is a cue to review your configurations and ensure you’re not unintentionally exposing your systems to risk.
As always, stay vigilant, keep your software up to date, and don’t let boilerplate advisories lull you into a false sense of security. Your users (and their data) will thank you for it.
Related Reading: