n8n Login Bug Let a Valid Token From One Provider Log You In as Someone Else
The workflow automation platform matched users on a single ID field and ignored who issued the token. On Enterprise setups with more than one login provider, that was enough to walk in as another person.
Key points
- N8n, a popular workflow automation platform, had a login flaw that let a valid token from one identity provider log an attacker in as a different user tied to a second provider.
- The bug only affected Enterprise instances configured to trust more than one external token issuer.
- N8n matched incoming tokens on the user ID field alone and did not check which system issued the token.
- No password was needed; the victim's credentials were never part of the attack path.
- Enterprise admins running multi-issuer setups should patch, remove any issuers they no longer need, and review recent logins for anomalies.
N8n handed out the wrong accounts at login.
The platform, used by companies to wire together internal tools and automate work, had a flaw in how it accepted single sign-on tokens. On Enterprise instances set up to trust more than one external login provider, n8n was matching users on the wrong piece of information.
When you log in through a company system, your identity provider hands the app a small signed document called a JWT, short for JSON Web Token. That token carries claims about who you are. Two of those claims matter here: sub, the user's ID inside that provider, and iss, which identifies which provider issued the token.
N8n was reading sub and ignoring iss.
So if issuer A produced a token with a sub value that matched a completely different person registered under issuer B, n8n would log the attacker straight into that person's account. The source of the token was never checked. The victim's password didn't come into it, and there's no phishing or cryptographic attack required. The attacker just needed a legitimate account on one trusted issuer and a colliding sub on another.
We've covered JWT-related flaws three times since 16 July 2026, and this one sits at the sharper end: the collision can happen silently, with no failed login to alert on.
Who is actually at risk here?
Only self-hosted n8n Enterprise customers who deliberately configured more than one external token issuer. A single-provider setup can't be hit, because there's no second issuer to borrow an ID from.
That narrows the blast radius. But for organisations running multi-issuer setups, such as large enterprises with contractor access or acquired subsidiaries on separate directories, the risk is real. Those are exactly the environments where two different people can end up with the same ID string under different providers.
The fix, as first reported by The Hacker News, is to check iss and sub together when looking up a local user, so a token maps only to the account created for that specific issuer.
What should n8n admins do now?
Update to the patched Enterprise release as soon as your change window allows.
Then do two things. Pull your authentication logs and look for successful logins where the same sub appears under different issuers. Confirm which issuers your instance actually trusts and remove any that are no longer needed.
If you run automations touching sensitive systems, customer data or production infrastructure, treat this as a reason to review who has been running those workflows over the past few months, not just who holds access today.
Should you notify regulators?
Any confirmed unauthorised access to personal data triggers standard breach-notification duties. Whether that lands under the ICO in the UK or the FTC in the US, a misrouted login counts as unauthorised access even when the underlying token was perfectly valid. Don't let the technical tidiness of the attack obscure what it actually is.
