Back to Blog
OpsecForge Security TeamAPI SecuritySources reviewed 2026-07-24

CVE-2026-59208: n8n Token Exchange Cross-Issuer Account Confusion

How CVE-2026-59208 let a valid JWT from one trusted issuer resolve to an account under another issuer, which versions are affected, and how to remediate it.

Primary source: authoritative reference

Severity: High — CVSS 4.0 score 7.6 | Published: June 24, 2026 | Status: Fixed in n8n 2.27.4 and 2.28.1

CVE-2026-59208 is an account-binding flaw affecting n8n instances configured with token exchange and more than one trusted external issuer. The vulnerable flow resolved an external identity to a local account using the JWT sub claim without also binding that account lookup to the token's iss claim.

An attacker still needs a valid token from a trusted issuer, and the token's subject must match a victim registered under another trusted issuer. The official advisory rates the issue High, not Critical. As of the latest NVD record reviewed on July 24, 2026, CISA's SSVC entry lists exploitation as none; this article does not claim known exploitation in the wild.

Who Is Affected?

The issue only affects n8n deployments where:

  • token exchange is enabled;
  • more than one trusted external issuer is configured; and
  • the installed version is older than 2.27.4, or is 2.28.0.

The two fixed release lines are:

  • n8n 2.27.4 for the 2.27 line;
  • n8n 2.28.1 for the 2.28 line.

If you are on a later supported version, verify that it includes one of those fixes.

How the Account Confusion Worked

In a multi-issuer setup, sub is only unique within an issuer's namespace. Two issuers can legitimately issue tokens containing the same subject value.

The vulnerable sequence was:

  1. n8n accepted a valid token from trusted Issuer A.
  2. The token contained a sub value also used by an account under trusted Issuer B.
  3. Account resolution used sub without binding it to iss.
  4. The request could authenticate as the account associated with Issuer B.

This is why verifying a signature is necessary but insufficient. The application must also verify that the issuer is authorized to assert that specific external identity.

What Correct Validation Requires

A safe token-exchange implementation should bind these values together:

  • Issuer (iss): the identity provider that issued the token;
  • Subject (sub): the identity within that issuer's namespace;
  • Audience (aud): the service for which the token was issued;
  • Tenant or organization: the local security boundary receiving the identity.

Conceptually, account lookup should use a compound identity such as (issuer, subject) rather than subject alone:

def resolve_external_identity(claims):
    issuer = require_trusted_issuer(claims["iss"])
    require_expected_audience(claims["aud"])

    account = db.find_account(
        external_issuer=issuer,
        external_subject=claims["sub"],
    )
    if not account:
        raise AuthenticationError("Unknown external identity")

    return account

This pseudocode illustrates the security invariant; it is not n8n source code.

Remediation

  1. Upgrade n8n. Install 2.27.4, 2.28.1, or a later supported release containing the fix.
  2. Reduce trusted issuers if you cannot upgrade immediately. The vendor advises using a single trusted issuer when multiple issuers are unnecessary.
  3. Disable token exchange if it is unused. The vendor lists this as a temporary mitigation.
  4. Review sessions issued through the affected flow. Use your own audit data to decide whether session invalidation is warranted; the advisory does not state that exploitation was observed.
  5. Audit other multi-issuer integrations. Search for account lookups keyed only by sub, email address, or another issuer-local identifier.

Temporary mitigations reduce exposure but do not replace upgrading.

Inspect JWT Claims Locally

When investigating a token, avoid pasting credentials into services that may log them. OpsecForge's JWT Decoder runs in the browser so you can inspect the header and payload locally.

Check iss, sub, aud, exp, and the declared algorithm, but remember: decoding claims is not signature verification. Your application must validate the signature, accepted algorithm, issuer, audience, expiry, and tenant binding using trusted configuration.

Key Takeaway

CVE-2026-59208 demonstrates a common multi-tenant authentication failure: treating a valid subject as globally unique. In federated systems, an external identity is normally the pair (issuer, subject). Keeping that binding intact during token exchange prevents one trusted issuer from speaking for accounts owned by another.

Primary Sources

Share this: