{"id":1827,"date":"2026-07-16T15:19:42","date_gmt":"2026-07-16T15:19:42","guid":{"rendered":"https:\/\/thedigitalfortress.us\/?p=1827"},"modified":"2026-07-16T15:19:42","modified_gmt":"2026-07-16T15:19:42","slug":"n8n-token-exchange-flaw-could-let-attackers-log-in-as-users-from-another-issuer","status":"publish","type":"post","link":"https:\/\/thedigitalfortress.us\/?p=1827","title":{"rendered":"n8n Token Exchange Flaw Could Let Attackers Log In as Users From Another Issuer"},"content":{"rendered":"
\n

\ue804<\/i>Swati Khandelwal<\/span>\ue802<\/i>Jul 16, 2026<\/span><\/span>Vulnerability \/ Web Security<\/span><\/p>\n<\/div>\n

\n
<\/a><\/div>\n

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<\/code> claim alone and ignored iss<\/code>.<\/p>\n

A valid token from issuer A carrying a sub<\/code> that belongs to someone under issuer B logged you in as them. Their password never came into it. n8n shipped the fix on June 24.<\/p>\n

The flaw is tracked as CVE-2026-59208<\/code><\/a>. The CVE record did not go public until July 9. n8n credits the report<\/a> to the GitHub account bearsyankees<\/a>, whose profile lists Strix, which makes an AI penetration testing agent.<\/p>\n

Strix says<\/a> it pointed out that the agent at the token-exchange flow and found the identity-binding bug there.<\/p>\n

Two issuers, one account<\/h2>\n

Token exchange is n8n’s Enterprise route for OEM partners who embed the product<\/a>, an RFC 8693 implementation<\/a> that spares their users a second login screen.<\/p>\n

The partner signs a short-lived JWT with its own key, n8n verifies it against a configured public key, matches the claims to a local account, and the user is in. Trusted keys go in N8N_TOKEN_EXCHANGE_TRUSTED_KEYS<\/code>, and the deployment docs<\/a> still tag the feature as preview.<\/p>\n

\n
\"Cybersecurity\"<\/a><\/div>\n<\/div>\n

The token itself checks out. The matching is the bug. A sub<\/code> value is only guaranteed to be unique inside the issuer that minted it. RFC 7519<\/a> asks that it be \u00abscoped to be locally unique in the context of the issuer\u00bb or else globally unique. The identifier for a user is therefore the pair, iss<\/code> plus sub<\/code>.<\/p>\n

<\/p>\n

n8n keyed on half of it. Nothing stops two issuers from emitting the same subject string, and when they do, both land on one n8n account.<\/p>\n

How big a deal is this<\/h2>\n

The flaw reaches an instance only if token exchange is switched on and the config trusts at least two external issuers. n8n says<\/a> nothing else is affected. Token exchange is Enterprise-only and still flagged as a preview, so the exposed set is small and specific: OEM deployments, where trusting a second issuer is a supported configuration.<\/p>\n

What the advisory does not pin down is how an attacker gets the token. It says only that they can obtain one. The practical question is whether an ordinary user at a trusted issuer can influence the sub<\/code> they receive. The public record does not answer it. GitHub’s CVSS 4.0 vector marks attack requirements as present and stops there.<\/p>\n

\"\"<\/a><\/div>\n

GitHub assigned that vector. As the CNA here, it puts CVE-2026-59208<\/code> 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<\/code> and CWE-346<\/code>. 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.<\/p>\n

Two weeks before the June 24 fix, the maintainers patched CVE-2026-54305<\/code><\/a>, 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.<\/p>\n

\n
\"Cybersecurity\"<\/a><\/div>\n<\/div>\n

The Hacker News has reached out to n8n for confirmation on the scope and impact of CVE-2026-59208<\/code> and will update this story with any response.<\/p>\n

Patch or cut the issuer list<\/h2>\n

CVE-2026-59208<\/code> 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<\/code> and stable<\/code> 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.<\/p>\n

If patching has to wait, work out what you are running: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS<\/code> 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.<\/p>\n

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.<\/p>\n

Neither release note mentions the fix. The Hacker News checked both: between them, the 2.27.4<\/a> and 2.28.1<\/a> changelogs cover a Python import fix, a Google Ads node upgrade, an AI workflow check, and a node-building change, and nothing about identity.<\/p>\n

The advisory is where this one lives. If your upgrade decisions run on changelogs, this is the kind of fix that slips past.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

\ue804Swati Khandelwal\ue802Jul 16, 2026Vulnerability \/ Web Security n8n, the workflow automation platform, handed out the wrong accounts at login. On Enterprise instances configured to trust more than one external token…<\/p>\n","protected":false},"author":1,"featured_media":1828,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[622,1290,70,2572,2571,602,979,826],"class_list":["post-1827","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-attackers","tag-exchange","tag-flaw","tag-issuer","tag-log","tag-n8n","tag-token","tag-users"],"_links":{"self":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/posts\/1827","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1827"}],"version-history":[{"count":0,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/posts\/1827\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=\/wp\/v2\/media\/1828"}],"wp:attachment":[{"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1827"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1827"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thedigitalfortress.us\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1827"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}