n8n Enterprise on alert: identity link failure between trusted emitters could allow you to log in as another user

n8n, the workflow automation platform, in late June, patched a serious failure that allowed you to log in as another user without knowing your password when the Enterprise instance had activated the "knock exchange" function and trusted more than one external emitter. In technical terms the root of the problem was a wrong identity link: the system compared only the incoming JWT claim "sub" with local users and did not consider the "iss" (issue)RFC 7519, and the exchange flow of tokens that n8n implements follows RFC 8693.

In practice the failure meant that a legitimate token signed by an A issuer that included a "sub" equal to that of a user created by the B issuer could be accepted by n8n as if it were that other user. The specific attack vector that would allow an attacker to get a valid token is not explained in the public notice; that leaves uncertainty as to whether a normal user in one of the emitters could force or get a given "sub." Public vulnerability databases reflect different assessments: the CNA assigned a high score in CVSS 4.0 while NVD listed it with a lower gravity in CVSS 3.1. CISA has recorded the incidence and, for the time being, has not confirmed active exploitation in the field.

The technical scope is, however, quite precise: it only affects Enterprise deployments that have enabled the token exchange and that trust at least two broadcasting keys configured in the N8N _ TOKEN _ EXCHANGE _ TRUSTED _ KEYS variable. That is, the exposed area is reduced and usually corresponds to OEM or integrated implementations where n8n accepts tokens signed by partners. n8n distributed the arrangement in specific versions of the product; if your environment uses an earlier version it should be considered vulnerable until it is updated.

If you manage or depend on a n8n Enterprise instance, the priority actions are clear and urgent: first, check the version you are running and plan the update to the most recent patch including correction. In parallel, if you cannot park immediately, reduce exposure by deactivating the token exchange function or restricting the configuration to rely only on a single issuer. Locate and review the N8N _ TOKEN _ EXCHANGE _ TRUSTED _ KEYS variable, confirm who the trusted emitters are and, if appropriate, remove unnecessary inputs until the final solution can be applied. These mitigation measures are temporary and, as technical warnings point out, do not replace the software update.

More additional defence measures include strengthening telemetry and records: enable and review authentication and token exchange looms in search of unusual login, implement alerts for newly created sessions with external identities, activate multifactor authentication for local accounts with privileges and reduce unnecessary permits in workflows and credentials. If your deployment supports external audit records or IMS, export these events for a wider correlation and to facilitate further investigation.

This vulnerability does not come in isolation: in the previous weeks n8n corrected a different Enterprise failure that allowed to manipulate OAuth credentials through dynamic credentials endpoints, suggesting that deployments with preview functionalities or OEM integrations deserve a particular and continuous review. To follow official communications and patches it is appropriate not to rely only on the usual changelils: the specific identity arrangement does not always appear in the package change notes, and the official information may reside in the security notice or the CVE base. Maintain active monitoring of supplier sources and public vulnerability repositories as NVD and product documentation in N8n documentation.

Finally, assess the need to inform the users concerned and to initiate a forensic analysis if there is evidence of unauthorized access. Although there is no public evidence of mass exploitation at the moment, the vector allows password-free access under specific conditions, and any exposure of credentials or unexpected workflows should be treated as a potential incident. The operational lesson is clear: when you trust external tokens, the identity link code must fully respect the iss + sub model and the implementations that simplify this verification are at risk. Review the configuration, apply patches and improve monitoring are essential steps to mitigate the problem.