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 that were 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 by the attacker; the victim's password was never involved in the attack path.
- Enterprise admins running multi-issuer setups should patch, review recent logins, and audit which issuers they actually trust.
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.
Here is what that means in plain terms.
When you log in through a company system, your identity provider (think Okta, Microsoft Entra, or Google) 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, which is the user's ID inside that provider, and iss, which says which provider issued the token.
n8n was looking at sub and ignoring iss.
So if issuer A said "this user's ID is 12345" and issuer B happened to have a completely different person whose ID was also 12345, a valid token from A could log the attacker in as B's user. The two IDs collided, and n8n did not check the source.
The victim's password never came into it. The attacker did not need to phish anyone, guess anything, or break any cryptography. They just needed a legitimate account on one trusted issuer and a matching sub value on another.
Who is actually at risk here?
Only self-hosted n8n Enterprise customers who deliberately configured more than one external token issuer. If your instance trusts a single identity provider, the collision cannot happen, because there is no second issuer to borrow an ID from.
That narrows the blast radius considerably. But for the organisations that do run multi-issuer setups (large enterprises with contractor logins, acquired subsidiaries, or partner tenants) the risk is real. Those are exactly the environments where two different people can end up with the same numeric or string ID under different providers.
The fix, as first reported by The Hacker News, is to check both iss and sub together when looking up a local user. That way a token is only ever mapped to the account that was 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 three things. Pull your authentication logs and look for successful logins where the same sub appears under different issuers. Confirm which issuers your instance is actually configured to trust and remove any you no longer need. Rotate credentials or API keys for any account that looks like it was accessed by someone who should not have had it.
If you run automations in n8n that touch sensitive systems (customer data, finance workflows, production infrastructure) treat this as a reason to review who has been running those workflows in the past few months, not just who has access today.
Regulator angle: any confirmed unauthorised access to personal data still triggers the usual breach-notification duties, whether that lands under the ICO in the UK, the FTC in the US, or the OAIC in Australia. A misrouted login is unauthorised access, even if the underlying token was valid.
