n8n’s Exchange Flaw Could Let Attackers Log

Overview

A critical flaw in n8n’s Enterprise token exchange feature has been disclosed, tracked as CVE‑2026‑59208. The vulnerability allowed attackers to log in as users from another issuer by exploiting how n8n matched JWT tokens. The issue was patched on June 24, 2026, but the CVE record only went public on July 9.

The Vulnerability Explained

• CVE‑2026‑59208 — improper identity binding in token exchange.
• n8n matched incoming JWTs to local accounts using only the sub claim, ignoring the iss (issuer) field.
• Result: a valid token from issuer A with a subject string belonging to issuer B could log you in as that user.
• Passwords were not required, making this a silent identity bypass.

This violates RFC 7519, which specifies that user identifiers must be scoped by both iss + sub to ensure uniqueness.

Scope & Impact

• Affects Enterprise instances with token exchange enabled and configured to trust multiple issuers.
• Token exchange is Enterprise‑only and flagged as preview, so exposure is limited to OEM deployments.
• Exploitation requires obtaining a valid token, though the advisory does not clarify how attackers might do so.

Severity Ratings

• GitHub CVSS 4.0 score: 7.6 (High).
• NVD CVSS 3.1 score: 6.8 (Medium).
• CISA SSVC assessment: exploitation status “none” as of July 13.
• No public proof‑of‑concept has been found.

Related Issues

Two weeks earlier, n8n patched CVE‑2026‑54305, another Enterprise‑only bug. That flaw allowed authenticated users to overwrite or revoke other users’ OAuth tokens due to missing ownership checks.

Patch & Mitigation

• Fixed in n8n versions 2.27.4 and 2.28.1.
• Latest stable release as of July 16 is 2.30.6.
• If patching is delayed:
  • Restrict to a single trusted issuer.
  • Disable token exchange entirely.

Both are short‑term measures; only patching fully remediates the risk.

Expert in the Cloud Insight

This flaw underscores the critical importance of proper identity binding in federated authentication systems. By ignoring the issuer field, n8n inadvertently allowed cross‑issuer impersonation — a subtle but dangerous bug. For enterprises embedding n8n, the lesson is clear: always patch promptly, audit token exchange configurations, and treat identity flows as high‑value attack surfaces.