CVE-2026-72772: n8n account takeover

CISO Take

n8n's Token Exchange Embed Login feature authenticates users by matching an incoming signed token's email claim to a local account, but fails to verify that the email was actually confirmed by the trusted issuer or that the issuer's permitted role ceiling covers that account. Any party able to obtain a token accepted by a configured trusted key — for example an identity provider that emits unverified email addresses — can impersonate any existing n8n user and gain full account control, including access to stored credentials and automations wired into that account's workflows. This only matters if embed login is enabled with at least one trusted key configured, which narrows exposure, and there is no public PoC, no Nuclei template, and no CISA KEV listing; EPSS sits at a low 0.00215, so opportunistic mass exploitation is unlikely right now. Because n8n workflows routinely hold LLM API keys and third-party integration secrets, a successful takeover of a privileged n8n account is a credential-exfiltration and automation-tampering risk, not just a login bypass. Patch to n8n 2.32.1 (or 2.31.5 on the older branch) immediately if embed login is enabled, and in the interim disable embed login or remove trusted key sources until patched, then audit account activity and workflow credential access logs for anomalies tied to embed-login sessions.

Sources: NVD GitHub Advisory EPSS ATLAS vulncheck.com

What is the risk?

This is a self-contained authentication-bypass flaw (CWE-640) with high potential impact — full account takeover — but a narrow precondition set: it only applies to n8n instances that have explicitly enabled embed login AND configured at least one trusted key/issuer. There is no CVSS score published, no CISA KEV listing, no known public exploit, and EPSS is very low, so exploitation likelihood in the wild is currently modest. However, exploitability itself is not technically hard — it requires obtaining or controlling a token from a trusted issuer that emits unverified email claims, which is plausible in federated/embed SSO setups using loosely configured IdPs. Given n8n's role as an AI agent orchestration platform frequently holding LLM API keys and third-party credentials inside workflows, a successful takeover has outsized downstream impact relative to its EPSS score. Overall: TRACK per CISA SSVC, but treat as urgent for any instance with embed login enabled.

How does the attack unfold?

Initial Access

Attacker obtains a validly-signed token from a trusted issuer configured on the n8n instance, where the issuer emits an unverified email claim matching a target victim account.

AML.T0091.000

Exploitation

n8n's Token Exchange Embed Login matches the token's email claim to a local account without checking verification status or the trusted key's role ceiling, authenticating the attacker as the victim.

AML.T0012

Post-Compromise Access

The attacker gains full control of the victim's n8n account, including access to workflow-stored credentials such as LLM API keys and connected service tokens.

AML.T0083

Impact

The attacker exfiltrates credentials, manipulates automations, or pivots into downstream systems and AI services orchestrated by the compromised account's workflows.

Initial Access

Attacker obtains a validly-signed token from a trusted issuer configured on the n8n instance, where the issuer emits an unverified email claim matching a target victim account.

AML.T0091.000

Exploitation

n8n's Token Exchange Embed Login matches the token's email claim to a local account without checking verification status or the trusted key's role ceiling, authenticating the attacker as the victim.

AML.T0012

Post-Compromise Access

The attacker gains full control of the victim's n8n account, including access to workflow-stored credentials such as LLM API keys and connected service tokens.

AML.T0083

Impact

The attacker exfiltrates credentials, manipulates automations, or pivots into downstream systems and AI services orchestrated by the compromised account's workflows.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 37% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Patch immediately to n8n >= 2.32.1 (or >= 2.31.5 on the 2.31.x branch), which is expected to enforce email-verification status and role-ceiling checks on token exchange embed login. If patching cannot happen immediately, disable the embed login feature or remove/disable all configured trusted key sources until the upgrade is applied — the vulnerability requires both to be active. Audit trusted issuer configurations to confirm whether any configured IdP is known to emit unverified email claims, and tighten issuer trust policies accordingly. After patching, review authentication logs for embed-login sessions around unexpected accounts or IPs, and rotate credentials stored in workflows for any accounts that may have been accessed via this path during the exposure window.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Privacy Violation Agent Framework AML.T0012 - Valid Accounts AML.T0083 - Credentials from AI Agent Configuration AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

GOVERN-1.5 - Processes for periodic review of third-party AI system components and access controls

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-72772?

n8n's Token Exchange Embed Login feature authenticates users by matching an incoming signed token's email claim to a local account, but fails to verify that the email was actually confirmed by the trusted issuer or that the issuer's permitted role ceiling covers that account. Any party able to obtain a token accepted by a configured trusted key — for example an identity provider that emits unverified email addresses — can impersonate any existing n8n user and gain full account control, including access to stored credentials and automations wired into that account's workflows. This only matters if embed login is enabled with at least one trusted key configured, which narrows exposure, and there is no public PoC, no Nuclei template, and no CISA KEV listing; EPSS sits at a low 0.00215, so opportunistic mass exploitation is unlikely right now. Because n8n workflows routinely hold LLM API keys and third-party integration secrets, a successful takeover of a privileged n8n account is a credential-exfiltration and automation-tampering risk, not just a login bypass. Patch to n8n 2.32.1 (or 2.31.5 on the older branch) immediately if embed login is enabled, and in the interim disable embed login or remove trusted key sources until patched, then audit account activity and workflow credential access logs for anomalies tied to embed-login sessions.

Is CVE-2026-72772 actively exploited?

No confirmed active exploitation of CVE-2026-72772 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-72772?

Patch immediately to n8n >= 2.32.1 (or >= 2.31.5 on the 2.31.x branch), which is expected to enforce email-verification status and role-ceiling checks on token exchange embed login. If patching cannot happen immediately, disable the embed login feature or remove/disable all configured trusted key sources until the upgrade is applied — the vulnerability requires both to be active. Audit trusted issuer configurations to confirm whether any configured IdP is known to emit unverified email claims, and tighten issuer trust policies accordingly. After patching, review authentication logs for embed-login sessions around unexpected accounts or IPs, and rotate credentials stored in workflows for any accounts that may have been accessed via this path during the exposure window.

What systems are affected by CVE-2026-72772?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

What is the CVSS score for CVE-2026-72772?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0083 Credentials from AI Agent Configuration

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: GOVERN-1.5

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

n8n before 2.32.1 (and before 2.31.5) is vulnerable to account takeover via the Token Exchange Embed Login feature. When a validly-signed incoming token was matched to a local account by its email claim, the service did not verify that the email claim was verified, nor that the trusted key's permitted role ceiling covered that account. As a result, anyone able to obtain a token accepted by a configured trusted key (for example, a trusted issuer emitting unverified email addresses) could authenticate as any existing user and gain full account control. This issue only affects instances where the embed login feature is enabled and at least one trusted key source is configured.

Exploitation Scenario

An organization enables n8n's embed login to let a partner portal authenticate users via SSO, trusting an identity provider that, for certain federated/social sign-in paths, issues tokens with an `email` claim that is not cryptographically or organizationally verified. An attacker registers an account with that issuer using an email address matching a high-privilege n8n user (e.g. an admin who owns workflows containing LLM API keys and database credentials), obtains a validly signed token, and presents it to n8n's Token Exchange Embed Login endpoint. Because n8n only checks that the email claim matches an existing local account — without verifying the claim was confirmed or that the issuer's role ceiling permits access to that account — the attacker is authenticated as the victim admin with full account privileges. From there, the attacker can open the admin's workflows, extract stored LLM/API credentials, exfiltrate connected data, or modify automations to establish persistence.

Weaknesses (CWE)

CWE-640 Weak Password Recovery Mechanism for Forgotten Password Primary CWE-640 Weak Password Recovery Mechanism for Forgotten Password

CWE-640 — Weak Password Recovery Mechanism for Forgotten Password: The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.

[Architecture and Design] Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.
[Architecture and Design] Do not use standard weak security questions and use several security questions.

Source: MITRE CWE corpus.