This n8n Login Flaw Let Attackers Hijack Accounts Using Tokens From Another Provider

Emily Davis · 2026-07-16

Imagine walking into your office, swiping your badge, and suddenly finding yourself logged into a coworker's computer. Their emails, their projects, their sensitive data—all yours, just because the system checked your badge number but forgot to check which building issued it. That's essentially what happened with n8n, the popular workflow automation platform. A critical flaw was discovered in n8n's Enterprise version. When companies configured it to trust multiple external token issuers—like different identity providers for separate departments or partners—the login system made a dangerous mistake. It matched an incoming JSON Web Token (JWT) to a local user based solely on the "sub" (subject) claim, completely ignoring the "iss" (issuer) field. ### How the Flaw Worked Let's break this down in plain English. Think of a JWT as a digital ID card. It has two key pieces of information: who you are (the sub claim, like an employee ID number) and who issued your card (the iss claim, like "Company A HR Department" or "Company B Security Office"). Normally, a secure system checks both. It says, "Okay, this person claims to be employee 12345 from Company A. Let me verify that employee 12345 exists in our system AND that this token was actually issued by Company A." n8n's flaw was that it only checked the first part. If you had a valid token from Issuer A with sub "12345", and someone else in your company had sub "12345" under Issuer B, you'd be logged in as them. Their password never mattered. The system just assumed you were the other person. ### Who Was at Risk? This vulnerability specifically impacted n8n Enterprise instances configured to trust more than one external token issuer. That's a common setup for: - Companies using multiple identity providers (Okta, Azure AD, custom OAuth servers) - Organizations that recently merged or acquired other companies - Businesses with separate authentication systems for contractors and employees - Any setup where user IDs might overlap between different issuers The scary part? An attacker didn't need to crack passwords or exploit complex vulnerabilities. They just needed a valid token from any trusted issuer with a sub that matched an existing user from a different issuer. ### Why This Matters for Security Teams This isn't just a technical glitch. It's a fundamental failure in authentication logic that could have serious consequences. Workflow automation platforms like n8n often handle sensitive data—API keys, database credentials, financial records, customer information. If an attacker can impersonate any user, they could: - Access and exfiltrate sensitive workflows - Modify automated processes to send data to unauthorized destinations - Escalate privileges if the hijacked account has admin rights - Launch further attacks against connected systems ### Lessons for Developers and Admins This flaw highlights a critical security principle: always validate the entire chain of trust, not just parts of it. When implementing JWT authentication, you must verify: - The issuer (iss claim) - The subject (sub claim) - The token's signature against the correct issuer's public key - The token's expiration and not-before times - That the combination of issuer and subject uniquely identifies a user For n8n administrators, the immediate fix was to update to the patched version. But the broader lesson applies to any system using federated authentication: never assume that user IDs are globally unique across different identity providers. ### The Takeaway This vulnerability serves as a wake-up call for anyone building or managing authentication systems. It's easy to focus on complex threats like zero-day exploits or sophisticated malware, but sometimes the most dangerous flaws are the simplest—like forgetting to check where a token came from. If you're using n8n Enterprise, ensure you're running the latest patched version. If you're using any system with multi-issuer authentication, audit your code to make sure you're validating both the who and the where of every token. Your users' accounts—and your data—depend on it.