Token Mixup: n8n's Cross-Issuer Login Flaw

On June 24, 2026, n8n patched CVE-2026-59208, a vulnerability in their token exchange mechanism that allowed attackers to authenticate as users from a different token issuer. If your Enterprise instance trusted multiple external identity providers, an attacker could present a valid token from Issuer A and gain access as a user from Issuer B.

The flaw wasn't due to a cryptographic break or a stolen secret. It was an identity verification gap: the system validated that tokens were properly signed but failed to verify which issuer signed them before granting access.

Timeline

Pre-June 24, 2026: Enterprise instances configured with multiple trusted token issuers were vulnerable. Any valid JWT from any trusted issuer could be used to impersonate users from other issuers.

June 24, 2026: n8n released a patch addressing CVE-2026-59208.

Current state: Patched versions enforce proper issuer validation during token exchange.

The window of exposure depended on when each organization enabled multi-issuer support. If you configured your instance to trust tokens from both your corporate IdP and a partner's SSO provider, you created a crossover risk between those populations.

Which Controls Failed

Three authentication controls broke down:

Issuer validation. The token exchange logic verified signatures but didn't confirm that the token's iss claim matched the user's registered issuer. RFC 7519 Section 4.1.1 defines the issuer claim as "a case-sensitive string containing a StringOrURI value." The spec requires recipients to reject tokens if they don't recognize or trust the issuer, but n8n's implementation trusted the signature without validating the issuer context.

Subject-issuer binding. User accounts weren't properly bound to their originating issuer. When the system looked up a user by subject claim, it didn't filter by issuer, allowing cross-issuer matches.

Token exchange scope. RFC 8693 Section 2.1 describes token exchange as a mechanism where "a client presents a token to an authorization server and receives a different token in response." The security model assumes you're validating not just token authenticity but also token applicability. n8n accepted tokens outside their intended scope.

What Standards Require

OWASP ASVS v4.0.3 Requirement 2.8.2: "Verify that OAuth and OpenID Connect authentication flows properly validate the authorization server's issuer identifier to prevent token substitution attacks."

Your authentication layer must verify three things about every token:

1. The signature is valid (cryptographic integrity)
2. The issuer is one you trust (issuer allowlist)
3. The token applies to this specific authentication context (subject-issuer binding)

NIST 800-53 Rev 5 IA-8(2): "The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies." When accepting federated credentials, you must validate both the credential itself and its issuing authority.

For multi-issuer environments, this means:

• Maintain an explicit list of trusted issuers
• Store which issuer each user account belongs to
• Reject tokens where iss doesn't match the user's registered issuer
• Log issuer mismatches as potential attacks

ISO 27001 Annex A.9.2.1 (User registration and de-registration): "A formal user registration and de-registration process shall be implemented to enable assignment of access rights." Your registration process must capture and enforce the user-issuer relationship. You can't treat all federated users as interchangeable.

Lessons and Action Items

Audit your issuer validation logic. Pull your authentication code and trace how it handles the iss claim. Does it:

• Extract the issuer from the token?
• Compare it against a trusted list?
• Match it to the user's registered issuer before granting access?

If you're using a library like jsonwebtoken (Node.js) or PyJWT (Python), check whether you're passing the issuer parameter to the verification function. Without it, you're only validating signatures.

Bind users to issuers in your data model. Your user table needs an issuer column. When you create a user from a federated login, store the iss claim value. During subsequent authentications, verify the incoming token's issuer matches the stored value. This prevents the crossover attack even if signature validation passes.

Test your multi-issuer configurations. If you trust more than one IdP, set up a test where:

1. User Alice exists with issuer "corporate.example.com"
2. User Bob exists with issuer "partner.example.com"
3. Bob attempts to authenticate with Alice's username but his own valid token

Your system should reject this. If it doesn't, you have the same vulnerability n8n patched.

Limit trusted issuers to what you actually need. Every additional trusted issuer expands your attack surface. If you configured three issuers but only actively use one, remove the unused two. When you do need multiple issuers, document why each one is trusted and review that list quarterly.

Implement issuer mismatch alerting. Log every case where a valid token's issuer doesn't match the user's registered issuer. These events should trigger security reviews. Legitimate issuer changes are rare and should go through a formal migration process.

Review your token exchange implementation. If you're using RFC 8693 token exchange, verify you're checking the act claim (actor) and the may_act claim when present. Token exchange adds complexity, and that complexity creates gaps. If you don't need token exchange, disable it.

The n8n vulnerability wasn't exotic. It was a straightforward failure to validate identity context. Your authentication system probably has similar logic, and if you're accepting tokens from multiple sources, you need to verify you're not making the same mistake.