GHSA-8342-988q-86cr: n8n: Account Takeover via Unverified Email Claim in Token Exchange Embed Login

Embed login lets n8n accept a signed token from a trusted issuer and sign the holder in. When the token's email claim matched a local account, n8n did two things wrong. It did not check that the trusted key's permitted role ceiling (allowedRoles) covered that account. It also did not check that the email claim was verified (CWE-345 and CWE-863).

So a token that is validly signed by a trusted key, for example from an issuer that emits unverified email addresses, is enough. The holder sets the email claim to an existing user's address, such as an owner or admin, and n8n signs them in as that user. That is full control of the account, with its workflows, credentials and settings.

The feature must be enabled and at least one trusted key source configured, so default instances are not exposed. The attacker still needs a token a trusted key accepts, which the CVSS 4.0 vector reflects with low privileges and a present attack requirement. Impact on confidentiality, integrity and availability is rated high.

Affected: n8n below 2.31.5, and 2.32.0. The advisory's Patches section names only 2.32.1, while its package data also lists 2.31.5 as a fixed release. Only instances with the embed login feature enabled (N8N_TOKEN_EXCHANGE_ENABLED) and at least one trusted key source configured are exposed.

Check the version:

npm ls n8n

Then check whether N8N_TOKEN_EXCHANGE_ENABLED is set in your environment.

Upgrade to n8n 2.32.1, or to 2.31.5 on that line, or later. For an npm install, run npm install [email protected].

Temporary mitigations from the advisory, none of which fully remove the risk:

• Set N8N_TOKEN_EXCHANGE_ENABLED=false to disable embed login.
• If you cannot disable it, limit network access to fully trusted parties and audit every trusted key and its allowedRoles assignment.
• Review auth_identity records for unexpected token-exchange entries linked to high-privilege accounts.

Query the auth_identity table for token-exchange entries tied to owner or admin accounts that you did not expect. Compare sign-in times for those accounts with the users' known activity. Review each configured trusted key, the issuers behind it, and whether those issuers verify email addresses. After an account was taken over, check its workflow edits, new credentials and API keys, and rotate what it could reach.

Impact

In an n8n instance, when a validly-signed incoming token was matched to a local account by its email claim, the service did not check that the trusted key's permitted role ceiling covered that account, nor that the email claim was verified. As a result, anyone able to obtain a token accepted by one of the configured trusted keys, for example a trusted issuer that emitted unverified email addresses, could authenticate as any existing user, gaining full account control.

This issue only affects instances where the embed login feature is enabled and at least one trusted key source is configured.

Patches

The issue has been fixed in n8n version 2.32.1. Users should upgrade to this version or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Disable the embed login feature by setting N8N_TOKEN_EXCHANGE_ENABLED=false.
• If embed login cannot be disabled, restrict network access to the n8n instance to fully trusted parties only, and audit all configured trusted keys and their allowedRoles assignments.
• Review auth_identity records for unexpected token-exchange entries linked to high-privilege accounts.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.