n8n CVE-2026-72772

Exploitation requires two non-default configuration conditions to be simultaneously active: (1) the embed login feature must be explicitly enabled via the N8N_TOKEN_EXCHANGE_ENABLED environment variable, which is disabled by default, and (2) at least one trusted key source must be configured in the instance. Beyond these deployment gates, the attacker must be able to obtain a JWT accepted by one of those configured trusted keys - specifically from an issuer that does not enforce email-address verification, which is common in development tenants, certain OAuth providers, and federated identity platforms with relaxed provisioning. Standard n8n deployments using local authentication, SAML, or OAuth flows that do not use the embed login feature are entirely unaffected. The role-ceiling bypass additionally requires that the trusted key's allowedRoles configuration permits access to the targeted account's privilege tier - though because this check was absent, any account reachable by email-claim matching was vulnerable regardless of its privilege level.

The CVSS 4.0 score of 8.9 with full High impact across confidentiality, integrity, and availability on both the vulnerable and subsequent systems accurately reflects worst-case outcomes when preconditions are satisfied, but the AT:P (specific attack requirements present) metric is the pivotal signal: exploitation is gated on the embed login feature being explicitly enabled via N8N_TOKEN_EXCHANGE_ENABLED and at least one trusted key source being configured - neither of which is a default state. This meaningfully contracts the exploitable population relative to the raw score. No EPSS data was supplied, and neither a CISA KEV listing nor public proof-of-concept code has been identified at time of analysis. Nevertheless, the attack logic is directly inferable from the advisory with no reverse-engineering required, and the enabling condition - a federated identity provider that issues tokens without verified email claims - is common in enterprise and municipal identity stacks; even a mid-sized municipal IT team in opole running a self-hosted n8n instance integrated with an Azure AD B2C tenant or a permissive OAuth provider should treat this as urgent if the embed login feature is active. For standard n8n deployments using built-in local authentication, risk is negligible. The role-ceiling bypass is a secondary impact that elevates privilege escalation risk even in environments where the email-verification bypass is partially mitigated by issuer controls.

An attacker who has registered with a federated identity provider that the n8n operator has designated as a trusted key source - such as a development tenant or a provider that issues email addresses without cryptographic verification - requests a token from that provider and sets or substitutes the email claim to match a known n8n administrator's address. The attacker submits this validly-signed token to the n8n embed login endpoint; because the service neither checks that the email claim is marked as verified nor validates the trusted key's role ceiling against the target account, it issues a fully authenticated session granting complete control of the administrator's account. No public exploit has been identified at time of analysis, but the attack steps are directly described by the vendor advisory.