CVE-2026-59208: n8n multi-issuer JWT sub collision

Q: Is CVE-2026-59208 actively exploited?

No confirmed active exploitation of CVE-2026-59208 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-59208?

Patch to n8n 2.27.4 (if on the 2.27.x line) or 2.28.1 (if on 2.28.x) immediately — both releases fix the identity resolution to validate `iss` alongside `sub`. As an interim workaround, audit your n8n instance's token-exchange configuration and reduce to a single trusted issuer wherever feasible; if multiple issuers are required, ensure `sub` values are namespaced/unique across issuers at the IdP level. Detection: review n8n authentication logs for unexpected identity resolutions where the presenting issuer does not match the account's normal issuer, and rotate any credentials stored in workflows owned by high-privilege accounts as a precaution post-patch.

Q: What systems are affected by CVE-2026-59208?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

Q: What is the CVSS score for CVE-2026-59208?

CVE-2026-59208 has a CVSS v3.1 base score of 6.8 (MEDIUM). The EPSS exploitation probability is 3.13%.

CISO Take

n8n instances configured with more than one trusted token-exchange issuer resolve external identities using only the JWT `sub` claim, ignoring the `iss` claim — so an attacker holding a valid token from Issuer A whose `sub` happens to match a victim's `sub` under Issuer B can log in as that victim. This matters because n8n workflows routinely store credentials for AI agent tools, LLM APIs, and vector databases, so an account takeover here can cascade into exposure of downstream AI service secrets and workflow automation. The attack requires the attacker to already control an account on a second trusted issuer and know or guess a matching `sub` value, which is why CVSS marks Attack Complexity High (AV:N/AC:H/PR:L) — it's not a mass-exploitable bug, but it's a clean identity-confusion flaw (CWE-287/CWE-346) in a package with 129 prior CVEs and a mid-tier 6.6/10 OpenSSF score. This CVE is not in CISA KEV, has no public exploit or Nuclei template, and EPSS sits at 0.00143 — patch to n8n 2.27.4 or 2.28.1 on your next maintenance window, and in the meantime audit whether your instance actually needs more than one trusted token-exchange issuer configured, since disabling that reduces exposure to zero.

Sources: NVD GitHub Advisory EPSS ATLAS OpenSSF

What is the risk?

Medium severity (CVSS 6.8) with high confidentiality and integrity impact but no availability impact. Exploitability is constrained by Attack Complexity High — the attacker needs a valid token from a trusted issuer AND a `sub` value that collides with a target victim's `sub` under a different trusted issuer, which is not opportunistic but is realistic in enterprise SSO setups with multiple federated IdPs (e.g., internal + partner/contractor issuers) or in multi-tenant deployments where issuer configs are broader than intended. No active exploitation (not in CISA KEV), no public PoC, no scanner coverage, and a very low raw EPSS score (0.00143) all point away from mass exploitation, but the underlying flaw — trusting `sub` without `iss` — is a well-understood identity-federation anti-pattern that a targeted attacker with SSO reconnaissance could exploit deliberately against a specific high-value account.

How does the attack unfold?

Reconnaissance

Attacker identifies that the target n8n instance trusts multiple token-exchange issuers and gathers a victim's `sub` claim value under one of those issuers.

AML.T0087

Identity Confusion Exploit

Attacker presents a valid JWT from a different trusted issuer whose `sub` matches the victim's, and n8n authenticates them as the victim because only `sub` is checked, not `iss`.

AML.T0091.000

Credential Access

Now inside the victim's n8n workspace, the attacker accesses stored credentials for connected AI agent tools, LLM APIs, or vector databases embedded in workflow configurations.

AML.T0083

Impact

Attacker exfiltrates AI service credentials or executes/modifies automation workflows as the victim, resulting in data leakage and unauthorized use of AI agent capabilities.

AML.T0098

Reconnaissance

Attacker identifies that the target n8n instance trusts multiple token-exchange issuers and gathers a victim's `sub` claim value under one of those issuers.

AML.T0087

Identity Confusion Exploit

Attacker presents a valid JWT from a different trusted issuer whose `sub` matches the victim's, and n8n authenticates them as the victim because only `sub` is checked, not `iss`.

AML.T0091.000

Credential Access

Now inside the victim's n8n workspace, the attacker accesses stored credentials for connected AI agent tools, LLM APIs, or vector databases embedded in workflow configurations.

AML.T0083

Impact

Attacker exfiltrates AI service credentials or executes/modifies automation workflows as the victim, resulting in data leakage and unauthorized use of AI agent capabilities.

AML.T0098

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.28.0, < 2.28.1	`2.28.1`
201.9K OpenSSF 6.7 Pushed 3d ago 51% patched ~6d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

6.8 / 10

EPSS

3.1%

chance of exploitation in 30 days

Higher than 87% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR Low

UI None

S Unchanged

C High

I High

A None

What should I do?

1 step

Patch to n8n 2.27.4 (if on the 2.27.x line) or 2.28.1 (if on 2.28.x) immediately — both releases fix the identity resolution to validate iss alongside sub. As an interim workaround, audit your n8n instance's token-exchange configuration and reduce to a single trusted issuer wherever feasible; if multiple issuers are required, ensure sub values are namespaced/unique across issuers at the IdP level. Detection: review n8n authentication logs for unexpected identity resolutions where the presenting issuer does not match the account's normal issuer, and rotate any credentials stored in workflows owned by high-privilege accounts as a precaution post-patch.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Privacy Violation Agent AML.T0012 - Valid Accounts AML.T0083 - Credentials from AI Agent Configuration AML.T0091.000 - Application Access Token AML.T0098 - AI Agent Tool Credential Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system operation and monitoring / access control

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

OWASP LLM Top 10

LLM08:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-59208?

n8n instances configured with more than one trusted token-exchange issuer resolve external identities using only the JWT `sub` claim, ignoring the `iss` claim — so an attacker holding a valid token from Issuer A whose `sub` happens to match a victim's `sub` under Issuer B can log in as that victim. This matters because n8n workflows routinely store credentials for AI agent tools, LLM APIs, and vector databases, so an account takeover here can cascade into exposure of downstream AI service secrets and workflow automation. The attack requires the attacker to already control an account on a second trusted issuer and know or guess a matching `sub` value, which is why CVSS marks Attack Complexity High (AV:N/AC:H/PR:L) — it's not a mass-exploitable bug, but it's a clean identity-confusion flaw (CWE-287/CWE-346) in a package with 129 prior CVEs and a mid-tier 6.6/10 OpenSSF score. This CVE is not in CISA KEV, has no public exploit or Nuclei template, and EPSS sits at 0.00143 — patch to n8n 2.27.4 or 2.28.1 on your next maintenance window, and in the meantime audit whether your instance actually needs more than one trusted token-exchange issuer configured, since disabling that reduces exposure to zero.

Is CVE-2026-59208 actively exploited?

No confirmed active exploitation of CVE-2026-59208 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59208?

Patch to n8n 2.27.4 (if on the 2.27.x line) or 2.28.1 (if on 2.28.x) immediately — both releases fix the identity resolution to validate `iss` alongside `sub`. As an interim workaround, audit your n8n instance's token-exchange configuration and reduce to a single trusted issuer wherever feasible; if multiple issuers are required, ensure `sub` values are namespaced/unique across issuers at the IdP level. Detection: review n8n authentication logs for unexpected identity resolutions where the presenting issuer does not match the account's normal issuer, and rotate any credentials stored in workflows owned by high-privilege accounts as a precaution post-patch.

What systems are affected by CVE-2026-59208?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

What is the CVSS score for CVE-2026-59208?

CVE-2026-59208 has a CVSS v3.1 base score of 6.8 (MEDIUM). The EPSS exploitation probability is 3.13%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0083 Credentials from AI Agent Configuration

AML.T0091.000 Application Access Token

AML.T0098 AI Agent Tool Credential Harvesting

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 2.27.4 and from 2.28.0 prior to 2.28.1, n8n instances configured with more than one trusted token-exchange issuer resolved external identities to local accounts using only the JWT sub claim and ignored the iss claim, allowing an attacker with a valid token from one trusted issuer and a sub matching a victim under another issuer to authenticate as that victim. This issue is fixed in versions 2.27.4 and 2.28.1.

Exploitation Scenario

A company runs n8n with SSO federated against both its primary corporate IdP and a secondary IdP used for contractors. An attacker with a legitimate but low-privilege contractor account discovers (via reconnaissance of SSO metadata, directory sync, or a leaked employee ID) that a target executive's `sub` claim under the corporate IdP happens to match a `sub` value the attacker can obtain or influence under the contractor IdP. The attacker authenticates to n8n with their valid contractor token; because n8n only checks `sub` and ignores which issuer it came from, the platform resolves them to the executive's account. The attacker now has access to the executive's n8n workspace, including stored OpenAI/Anthropic API keys and internal automation workflows, which they exfiltrate or abuse for further access.

Weaknesses (CWE)

CWE-287 Improper Authentication Primary CWE-287 Improper Authentication Primary CWE-346 Origin Validation Error Primary CWE-346 Origin Validation Error Primary CWE-346 Origin Validation Error Primary CWE-287 Improper Authentication CWE-346 Origin Validation Error

CWE-287 — Improper Authentication: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.