n8n Token Exchange Flaw: Impersonation via `sub` Claim Bypass

Overview: Critical Authentication Bypass in n8n Enterprise

A significant authentication bypass vulnerability has been identified in n8n, the popular workflow automation platform. This flaw, affecting n8n Enterprise instances configured to trust multiple external token issuers, allows an attacker to log in as another user by leveraging a specific token exchange weakness. The issue stems from n8n’s logic matching incoming JSON Web Tokens (JWTs) based solely on the sub (subject) claim, while ignoring the iss (issuer) claim, thereby creating a critical impersonation vector. This oversight allows a valid token from one issuer, possessing a sub claim associated with a user under a different issuer, to grant unauthorized access to that user’s account without requiring their password.

This vulnerability represents a serious security concern for organizations utilizing n8n Enterprise, particularly those integrating with multiple identity providers or federated authentication systems. Successful exploitation could lead to unauthorized access to sensitive workflows, data manipulation, and potential Privilege Escalation within the n8n environment. The details of this flaw underscore the critical importance of robust authentication validation mechanisms, especially when dealing with complex multi-issuer environments, as reported by The Hacker News.

Technical Analysis: How Attackers Exploit n8n sub Claim

The core of this n8n Enterprise authentication flaw lies in the platform’s handling of external token validation. When an n8n Enterprise instance is set up to trust more than one external token issuer, its authentication mechanism makes a critical error. Instead of verifying both the sub claim (identifying the user) and the iss claim (identifying the token’s origin issuer), n8n only validates the sub claim against its internal user database. This creates a dangerous scenario:

1. Multiple Issuer Configuration: An n8n Enterprise instance is configured to accept tokens from Issuer A and Issuer B.
2. User sub Collision: A legitimate user (user@example.com) exists under Issuer B, whose sub claim is user_id_123.
3. Attacker’s Token: An attacker obtains a valid token from Issuer A. This token’s validity from Issuer A is not in question. The attacker then crafts or manipulates this token (or an identity provider misconfiguration allows them to obtain one) such that its sub claim is also user_id_123.
4. Bypass: When n8n receives this token from Issuer A, it correctly validates the token’s signature and expiration from Issuer A. However, when it attempts to match the token to a local user, it only looks at the sub claim (user_id_123). Since user_id_123 is associated with user@example.com (from Issuer B’s context), n8n incorrectly logs the attacker in as user@example.com.

The critical aspect here is that n8n completely disregards the iss claim. This means that a user identified as user_id_123 by Issuer A should be treated as distinct from user_id_123 by Issuer B, even if the string values are identical. The absence of this issuer-specific context leads to the impersonation. This particular TTP highlights a fundamental breakdown in trust boundary enforcement when validating identity tokens, allowing for cross-issuer account takeovers.

Implications for n8n Enterprise Authentication Flaw

Organizations running affected n8n Enterprise versions face significant risks. The platform’s role in automating workflows often involves access to sensitive systems, data, and third-party services. An attacker gaining unauthorized access via this token exchange flaw could:

• Manipulate Workflows: Alter, disable, or create malicious workflows that could trigger actions within integrated systems.
• Data Exfiltration: Access and exfiltrate sensitive data processed or stored within n8n or its connected services.
• System Compromise: Use n8n’s integrations to launch further attacks against internal or external systems.
• Reputational Damage: A breach through such a fundamental flaw can severely impact an organization’s reputation and trust with its clients.

Given the nature of n8n’s capabilities, this vulnerability could potentially serve as a pivot point for broader compromises, making it a high-priority concern for security teams.

Actionable Recommendations: n8n Token Exchange Vulnerability Mitigation

To address this critical flaw, security professionals must prioritize immediate action to secure their n8n Enterprise deployments. Effective n8n token exchange vulnerability mitigation requires a multi-faceted approach:

• Primary Remediation: Comprehensive Claim Validation: The most crucial step is to ensure that n8n instances are configured to validate both the sub and iss claims of any incoming JWTs. This ensures that a sub claim is only matched to a local user if it originates from the correct associated issuer. Organizations should review their n8n authentication configurations to confirm this strict validation is in place. If n8n does not offer an immediate configuration option for this, a platform update from the vendor would be necessary.
• Patching and Updates: Monitor n8n’s official security advisories and promptly apply any patches or updates released to address this specific vulnerability. Staying current with software versions is a foundational security practice.
• Audit and Monitoring: Review authentication logs for any unusual login attempts, especially those originating from unexpected issuers or involving users with sub claims that might be common across multiple identity providers. Implement enhanced monitoring for IoC related to unusual activity in n8n workflows.
• Zero Trust Principles: Implement a Zero Trust approach to identity and access management. Verify everything, and trust nothing by default. This includes strong multi-factor authentication for all users and least privilege access.
• Identity Provider Security: Ensure that all integrated external identity providers are securely configured and follow best practices to prevent token manipulation or misissuance.