"n8n, the workflow automation platform, handed out the wrong accounts at login."
How n8n's token-exchange is supposed to work
n8n's Enterprise token exchange implements RFC 8693 as an OEM convenience: a partner can sign a short-lived JWT and n8n will verify it against a configured public key, map its claims to a local account, and skip a second login screen. Trusted keys are stored in the N8N_TOKEN_EXCHANGE_TRUSTED_KEYS environment setting, and the feature is still marked as a preview in deployment documentation.
The identity model for JWTs relies on two claims: iss (issuer) and sub (subject). RFC 7519 expects sub to be unique in the context of its issuer, making the pair (iss, sub) the proper identifier for a user. The token-exchange flow verifies the token itself but must also bind the token to the correct issuer when associating it with a local account.
The identity‑binding bug (CVE-2026-59208)
Instead of matching the issuer-plus-subject pair, certain n8n releases keyed on the sub claim alone. That meant a valid token from issuer A carrying a sub that belongs to someone under issuer B could log the bearer in as that B-issued account without supply of a password. n8n shipped a corrective update on June 24; the flaw is tracked as CVE-2026-59208 and the public CVE record appeared on July 9.
n8n credits the report to the GitHub account bearsyankees, whose profile lists Strix, described in the advisory as maker of an AI penetration‑testing agent. Strix says it pointed out the identity‑binding problem at the agent/token‑exchange flow.
Scope, severity, and public assessments
The bug only affects deployments where token exchange is enabled and the configuration trusts more than one external issuer. Token exchange is Enterprise-only and remains a preview feature, so the exposed set is narrow: OEM deployments that deliberately trust multiple issuers.
As the CNA, GitHub assigned CVE-2026-59208 a CVSS 4.0 score of 7.6 (high). The NVD recorded the issue at 6.8 on CVSS 3.1 (medium) and listed CWE-287 and CWE-346. CISA's July 13 SSVC assessment recorded exploitation as none. The Hacker News found no public proof‑of‑concept in searches on July 16; GitHub's CVSS vector marks attack requirements as present but does not expand on exploitability.
Patch availability and short-term mitigations
The fix first appeared in n8n releases 2.27.4 and 2.28.1; any version below 2.27.4 and 2.28.0 is affected. On July 16, n8n's npm package carried 2.30.6 on both its latest and stable tags. n8n ships frequent minor releases, so operators are urged to check the tag and take the newest stable build their deployment supports.
If an immediate upgrade is impractical, the advisory recommends two stopgap measures: reduce the trusted issuer list to a single signer or turn the token‑exchange preview feature off entirely. n8n's advisory notes these steps as short‑term mitigations and cautions they do not fully eliminate the risk; by n8n's scope statement, an instance with token exchange off is not affected.
- Check N8N_TOKEN_EXCHANGE_TRUSTED_KEYS for how many issuers are trusted.
- Verify whether token exchange (the preview flag) is enabled in each Enterprise deployment.
- Plan an upgrade path to 2.27.4, 2.28.1, or a later stable version such as 2.30.6 where supported.
What this means for OEM partners, enterprise security teams, and maintainers
OEM partners operating n8n with multiple trusted issuers are the principal group at risk; they should audit their trusted key lists, consider temporarily disabling token exchange, and accelerate updates to the fixed releases.
Enterprise security teams should treat this as a configuration‑dependent vulnerability: verify whether token exchange is enabled in their environments, confirm how many issuers are trusted, and prioritize patching affected releases. They should also review recent related advisories — maintainers patched CVE-2026-54305, an Enterprise-only issue, roughly two weeks before the June 24 fix — to ensure they have corrected all known Enterprise surface problems.
Maintainers and operators who rely on changelogs for upgrade decisions should note that neither the 2.27.4 nor 2.28.1 release notes mention the identity fix; the changelogs list unrelated items such as a Python import fix, a Google Ads node upgrade, an AI workflow check, and node-building changes. The identity‑binding patch lives in the advisory, not the release notes, and can be missed if teams rely solely on changelog summaries.
Two concrete yardsticks remain: if token exchange is disabled, the instance is unaffected; and if an operator trusts only one external issuer, the specific cross‑issuer collision that the bug exploited cannot occur. Beyond those facts, the public record stops short of demonstrating how easily an attacker can obtain a token whose sub collides across issuers — a practical question the advisory notes but does not answer.
https://thehackernews.com/2026/07/n8n-token-exchange-flaw-could-let.html
