n8n Token Exchange Flaw Could Let Attackers Log In as Users From Another Issuer
A vulnerability in n8n's token exchange feature could allow attackers to log in as users from another issuer. The flaw, tracked as CVE-2026-59208, was fixed on June 24, but the CVE record did not go public until July 9.
Intelligence analysis by Llama
n8n's token exchange feature, used by OEM partners, allows users to log in without a second login screen. However, a bug in the feature could allow attackers to log in as users from another issuer by matching the sub claim to a local user, ignoring the iss claim.
Imagine you have a special key that lets you into a house. But the key has a problem - it's not unique to your house. Anyone with the same key can get in. That's what happened with n8n's token exchange feature. It let attackers use a key from one house to get into another house, without needing the password.
Analysis
A Critical Flaw in n8n's Token Exchange Feature
The token exchange feature in n8n, a workflow automation platform, has a critical flaw that could allow attackers to log in as users from another issuer. This vulnerability, tracked as CVE-2026-59208, was fixed on June 24, but the CVE record did not go public until July 9.
The flaw is caused by n8n's matching of the sub claim to a local user, ignoring the iss claim. This means that a valid token from issuer A carrying a sub that belongs to someone under issuer B could log the user in as them, without their password ever being required.
The vulnerability affects n8n's Enterprise instances configured to trust more than one external token issuer. n8n has confirmed that nothing else is affected by this flaw, and that token exchange is Enterprise-only and still flagged as a preview.
The advisory does not pin down how an attacker gets the token, but it does say that they can obtain one. The practical question is whether an ordinary user at a trusted issuer can influence the sub they receive. The public record does not answer this question.
GitHub's CVSS 4.0 vector marks attack requirements as present and stops there. GitHub assigned that vector. As the CNA here, it puts CVE-2026-59208 at 7.6 on CVSS 4.0, high. NVD puts the same bug at 6.8 on CVSS 3.1, medium, and has not issued a 4.0 assessment at all; its record carries 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.
Two weeks before the June 24 fix, the maintainers patched CVE-2026-54305, another Enterprise-only flaw. It lets any authenticated user overwrite or revoke another user's stored OAuth tokens through the Dynamic Credentials endpoints. That one was a missing ownership check, not an identity binding. Different bug, same surface.
The Hacker News has reached out to n8n for confirmation on the scope and impact of CVE-2026-59208 and will update this story with any response.
Patch or cut the issuer list CVE-2026-59208 affects every n8n release below 2.27.4 and version 2.28.0. The fix first landed in 2.27.4 and 2.28.1. Those are the floor. On July 16, n8n's npm package carried 2.30.6 on both its latest and stable tags. It ships a new minor most weeks by its own account, so check the tag and take the newest stable build your deployment supports.
If patching has to wait, work out what you are running: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS holds the trusted signing keys, and a separate preview flag controls whether token exchange is on at all. Cut back to a single trusted issuer, or turn the feature off. The advisory calls both short-term measures and says neither fully remediates the risk. That is boilerplate, identical in at least three other n8n advisories, including the June 10 one.
By n8n's own scope statement, an instance with token exchange off is not affected. Neither release note mentions the fix. The Hacker News checked both: between them, the 2.27.4 and 2.28.1 changelogs cover a Python import fix, a Google Ads node upgrade, an AI workflow check, and a node-building change, and nothing about identity. The advisory is where this one lives.
If your upgrade decisions run on changelogs, this is the kind of fix that slips past.
Key points
- n8n's token exchange feature has a critical flaw that could allow attackers to log in as users from another issuer
- The flaw was fixed on June 24, but the CVE record did not go public until July 9
- The vulnerability affects n8n's Enterprise instances configured to trust more than one external token issuer
- n8n has confirmed that nothing else is affected by this flaw
- The advisory does not provide clear guidance on how to fully remediate the risk
n8n has fixed the flaw and released a patch. Users can update their instances to the latest version to fix the issue. Additionally, n8n has provided guidance on how to mitigate the risk by cutting back to a single trusted issuer or turning the feature off.
The flaw was not discovered until after the patch was released, and it's unclear how many instances were affected. Additionally, the advisory does not provide clear guidance on how to fully remediate the risk, and users may need to take additional steps to ensure their instances are secure.
