n8n Flaw Risks Multi-Issuer Hijacking

When enterprise platforms integrate external authentication providers, the integrity of that connection rests on how they interpret digital identity claims. A recently disclosed flaw in n8n, the workflow automation platform, demonstrated that relying on partial information for user identification can bypass security controls entirely.

Identity Binding Failure

The issue stems from how n8n manages token exchange for OEM partners, a feature that simplifies logins by allowing partners to provide their own JWTs. The platform, which utilizes an RFC 8693 implementation to handle these tokens, failed to properly validate the full identity context during the verification process. Instead of verifying both the issuer (iss) and the user subject (sub) as required by standards like RFC 7519, the platform focused solely on the subject claim.

Because the sub claim is typically only unique within the specific domain of the issuer that generated it, this behavior created a catastrophic security gap. If an instance was configured to trust multiple external issuers, an attacker could potentially use a valid token from one source to masquerade as a user belonging to another, as long as the user identifiers overlapped. This effectively stripped the authentication process of its ability to distinguish between distinct users from different origins.

Scope and Technical Impact

The vulnerability, identified as CVE-2026-59208, was formally credited to the security firm Strix. While the flaw exposes a significant oversight in enterprise identity management, the practical exploitation requirements remain somewhat opaque in the public record.

Strix says it pointed out that the agent at the token-exchange flow and found the identity-binding bug there.

— Strix, AI penetration testing agent firm

• CVE-2026-59208 carries a CVSS 4.0 score of 7.6 (High) assigned by GitHub.
• NVD lists the same bug with a CVSS 3.1 score of 6.8 (Medium).
• The fix is included in versions 2.27.4 and 2.28.1 and later.
• Exploitation was recorded as 'none' by CISA as of July 13.

Patching and Operational Risks

The fix for this vulnerability was quietly shipped by n8n on June 24, though the details of the patch were noticeably absent from official release notes. For administrators who rely on standard changelogs to inform their update cycles, the nature of this security correction could easily go unnoticed. Those currently running versions below 2.27.4 or 2.28.0 remain at risk if they have enabled the token exchange feature.

If immediate patching is not feasible, administrators are advised to review their environment configuration. The N8N_TOKEN_EXCHANGE_TRUSTED_KEYS environment variable controls which issuers are granted trust. Reducing this configuration to a single trusted issuer—or disabling the token exchange feature entirely—serves as a temporary mitigation until the software can be upgraded to the latest stable release.

Consequences for Enterprise Deployments

This incident underscores the inherent risks associated with implementing complex authentication flows, particularly in preview-status features. For organizations leveraging n8n in OEM or multi-tenant configurations, the reliance on incomplete identity validation highlights a critical need for rigorous testing of third-party integration points. Because the vulnerability was not explicitly documented in changelogs, it serves as a reminder to security teams that official advisories remain the primary source of truth for critical security patches, regardless of the information provided in routine feature updates. Relying on partial identity claims remains a high-stakes vulnerability in any architecture where user data is partitioned across multiple authentication sources.