The n8n token-exchange vulnerability highlights a subtle but serious identity-security risk in enterprise workflow automation platforms.

n8n is commonly used to connect applications, APIs, cloud services, databases, SaaS platforms, AI agents, and internal business workflows. That makes its authentication model especially important. If an attacker can enter n8n as the wrong user, the impact may go far beyond one dashboard login.

The flaw affected Enterprise deployments using the token-exchange feature with more than one trusted external token issuer. In simple terms, n8n accepted a valid token from one issuer and matched the user only by the subject value, without properly considering which issuer created that token.

This matters because a subject value is not guaranteed to be globally unique across all identity providers. The same subject identifier may exist under different issuers. The correct identity binding should consider both the issuer and the subject together. Matching only half of that identity pair can result in one user being treated as another user from a different issuer.

The practical result is account confusion. An attacker with access to a valid token from one trusted issuer could potentially be logged in as a different user associated with another issuer, if the subject values collide. The victim’s password would not need to be known or stolen.

This is especially serious in OEM and multi-issuer environments where multiple external identity providers are trusted by the same n8n instance. These environments often exist because organizations are embedding n8n into larger platforms, partner portals, customer workflows, or managed-service offerings.

The exposure is not universal. It applies only where token exchange is enabled and where more than one issuer is trusted. But for affected deployments, the risk is meaningful because workflow platforms often hold powerful connections to other systems.

A compromised n8n account may expose stored credentials, OAuth tokens, API keys, workflow logic, customer data, automation history, and connected business systems. If the account has administrative or workflow-editing permissions, the attacker may also be able to modify automations, create new integrations, exfiltrate data, or trigger actions in connected applications.

Organizations using n8n Enterprise should immediately confirm whether token exchange is enabled and whether multiple issuers are configured. Affected instances should be upgraded to a fixed version, with the latest stable release preferred wherever possible.

Where immediate patching is not possible, organizations should reduce the trusted issuer list to a single issuer or disable token exchange until the upgrade is completed. This should be treated only as a temporary mitigation, not as a replacement for patching.

Security teams should also review authentication logs, token-exchange activity, unexpected user sessions, unusual workflow changes, new credentials, modified OAuth connections, and suspicious access to high-privilege accounts.

The more uncomfortable lesson is that identity systems fail not only because passwords are stolen. They can also fail because two valid pieces of identity data are joined incorrectly. Apparently, even authentication can become confused when humans ask too many systems to trust each other.

This incident is also a reminder that release notes alone are not always enough for vulnerability management. Security fixes may not always appear clearly in ordinary changelogs. Teams running critical automation platforms should track vendor advisories, CVEs, GitHub security notices, and deployment-specific security guidance.

The key lesson is that workflow automation platforms should be treated like privileged infrastructure. They do not merely move data between systems; they often hold the authority to act across many systems. If identity binding is weak, one misplaced trust decision can become access to workflows, credentials, and business operations far beyond the original login.

n8n, the workflow automation platform, handed out the wrong accounts at login. On Enterprise instances configured to trust more than one external token issuer, it matched an incoming JWT to a local user on the sub claim alone and ignored iss. A valid token from issuer A carrying a sub that belongs to someone under issuer B logged you in as them. Their password never

Source: n8n Token Exchange Flaw Could Let Attackers Log In as Users From Another Issuer via The Hacker News — published 16 Jul 2026.