CVE-2026-72772 is an account takeover flaw in the n8n Token Exchange Embed Login feature. The service matched a signed token to a local account by email without checking that the email was verified. The record scores it 8.8, High. Upgrade to 2.32.1 or 2.31.5, or turn the feature off.
What's affected
The record says n8n before 2.32.1, and before 2.31.5, is affected. The GitHub advisory lists affected versions below 2.32.1 and below 2.31.5, with patched versions at 2.31.5 and 2.32.1 in its table. Its prose says the issue is fixed in 2.32.1. If you run the 2.31 line, check the advisory before choosing a target. The safe choice is 2.32.1.
The flaw only affects instances where the embed login feature is enabled and at least one trusted key source is configured. The service also did not check that the trusted key's permitted role ceiling covered the account it matched. Anyone who could get a token accepted by a trusted key, such as a trusted issuer that emits unverified email addresses, could sign in as any existing user.
The weakness class is CWE-640. VulnCheck lists the CWE name as weak password recovery mechanism, which fits loosely, so read the advisory text for the real mechanism.
How to check if you're exposed
Find the version of every n8n instance you run, including containers and any copy bundled in another product.
n8n --version
docker exec <container-name> n8n --version
npm ls n8n
If the version is below the patched release for your line, you are in the affected range. Remember that n8n often runs as a base image tag in Docker or Kubernetes, so check image tags in your manifests as well as running hosts. A dependency scan of the repository that holds your deployment files will surface pinned n8n packages. The free in-browser scan at gold.safeguard.sh/scan accepts a manifest and lists known CVEs for what it finds.
Then see whether the feature is on. The advisory names the variable that controls it.
env | grep N8N_TOKEN_EXCHANGE_ENABLED
If it is set to false, you are not using embed login. If it is unset or true, check whether any trusted keys are configured, and which roles they allow. The advisory also suggests reviewing auth_identity records for token exchange entries tied to high privilege accounts.
What to do now
- Upgrade n8n to 2.32.1, or to 2.31.5 on the 2.31 line.
- If you do not use embed login, set N8N_TOKEN_EXCHANGE_ENABLED=false.
- If you must keep it on, restrict network access to the instance to trusted parties and audit every trusted key and its allowedRoles setting.
- Review auth_identity records for unexpected token exchange entries linked to admin or owner accounts.
- Ask each token issuer whether it emits unverified email addresses, and fix that at the source.
- After patching, reset sessions for high privilege accounts if you found anything odd in the audit.
Why it matters
Matching accounts by email is only safe when the email is proven. A signed token proves who signed it, not that the address inside it belongs to the person holding the token. If the issuer does not verify addresses, then the token proves very little about the account it names.
The record rates this 8.8 High under CVSS 3.1. The GitHub advisory rates it High at 8.9 and VulnCheck says high at 8.9, both under CVSS 4.0. The numbers line up. What differs is the fix wording, where the advisory text names only 2.32.1 while its version table also lists 2.31.5. Neither source reports exploitation, and the CVE is not in the CISA KEV catalog. The exposure is narrow, since both the feature and a trusted key must be present. Where they are, the outcome is full account control.
Quick check
Is every n8n instance at risk from CVE-2026-72772?
No. Only instances with the embed login feature enabled and at least one trusted key source configured.
How do I turn the feature off?
Set N8N_TOKEN_EXCHANGE_ENABLED to false, as the advisory suggests as a short term step.
Sources
Last reviewed: 18 October 2026.
