Which versions of n8n are affected by EUVD-2026-56098?

A critical authentication bypass in n8n's Token Exchange Embed Login feature enables account takeover for users whose email is claimed in any validly-signed token from a configured trusted issuer.. A patch is available.

How to fix or mitigate EUVD-2026-56098?

Within 24 hours: audit your n8n deployment configuration to confirm whether Token Exchange Embed Login with trusted issuer integration is in use; if enabled, assess the risk posture of connected integrations and document which users or workflows could be targeted. Within 7 days: perform controlled deployment of n8n version 2.32.1 (or 2.31.5 for prior release line users) in a non-production environment, verify application compatibility, and schedule production upgrade during a maintenance window. Within 30 days: audit n8n access logs and token exchange events during the exposure period for suspicious patterns (unusual email claims, impossible-origin logins, account access outside normal hours), force password reset for any accounts showing anomalous activity, and review and re-baseline your trusted issuer configuration to enforce minimal necessary token scopes and role ceiling policies.

n8n EUVD-2026-56098

Q: What is the CVSS score of EUVD-2026-56098?

EUVD-2026-56098 has a CVSS 4.0 base score of 8.9 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-72772 HIGH

Weak Password Recovery Mechanism for Forgotten Password (CWE-640)

2026-08-11 VulnCheck

GHSA-cwxf-925x-2ccm

Information Disclosure Microsoft N8n N8N Io

8.9

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.9 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.9 HIGH

No n8n privileges required (PR:N) since the external token is the credential; AC:H reflects non-default embed login configuration plus requirement to obtain a valid issuer token; S:C because attacker accesses a different account's scope.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Aug 11, 2026 - 13:17 EUVD

Source Code Evidence Fetched

Aug 11, 2026 - 12:54 vuln.today

Analysis Generated

Aug 11, 2026 - 12:54 vuln.today

CVE Published

Aug 11, 2026 - 12:17 cve.org

HIGH 8.9

DescriptionCVE.org

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.

AnalysisAI

Account takeover in n8n before 2.32.1 (and before 2.31.5 in the prior release line) is enabled by two simultaneous omissions in the Token Exchange Embed Login feature: the platform accepts an incoming JWT's email claim without confirming the issuer has cryptographically verified that address, and it does not enforce the trusted key's configured role ceiling against the matched local account. An attacker able to obtain any validly-signed token from a configured trusted issuer - including issuers that routinely emit unverified email addresses as part of their standard flows - can present that token with a victim user's email and be granted a fully authenticated n8n session with complete account control. No public exploit has been identified at time of analysis; however, the vulnerability is exploitable in straightforward steps once both deployment preconditions are satisfied.

Technical ContextAI

n8n is a Node.js workflow automation platform distributed via npm under the package identifier n8n-io/n8n. Its Token Exchange Embed Login feature implements a JWT-based single-sign-on bridge that allows an embedding parent application to pass identity tokens signed by operator-configured trusted key sources directly to n8n, which then resolves the token to a local account by matching the email claim. The root cause is the complete absence of two orthogonal checks: first, the service did not validate the email_verified claim (or an equivalent signal) from the issuer, permitting any token - even those from issuers whose email-address provisioning is unverified - to drive account resolution; second, it did not compare the matched account's privilege level against the allowedRoles ceiling configured for the trusted key, defeating the operator's intended access-tier boundaries. NVD classifies this under CWE-640 (Weak Password Recovery Mechanism), which is an apparent misclassification - the root cause more precisely maps to CWE-287 (Improper Authentication) or CWE-346 (Origin Validation Error). The affected CPE is cpe:2.3:a:n8n-io:n8n:*:*:*:*:*:*:*:*. The CVSS 4.0 vector's AT:P metric correctly captures that specific deployment preconditions must be present before exploitation is possible.

RemediationAI

The vendor-released patch is n8n 2.32.1 (or 2.31.5 for the prior release line), incorporating fix commit f69dfc6dd2178a14ea1624d2e1d403c2e755042f; upgrade is the only complete remediation. Full details are in the advisory at https://github.com/n8n-io/n8n/security/advisories/GHSA-8342-988q-86cr. If immediate upgrade is not feasible, set the environment variable N8N_TOKEN_EXCHANGE_ENABLED=false to disable the embed login feature entirely - this eliminates the attack surface but removes all embed login functionality for legitimate users, which may disrupt embedded deployments. If disabling the feature is operationally impossible, restrict network access to the n8n instance to fully trusted parties only; this reduces external exposure but does not protect against insider threats or compromise of trusted network hosts. As a detection and containment measure, audit all configured trusted keys and their allowedRoles assignments, and review auth_identity records for unexpected token-exchange entries linked to high-privilege accounts to identify potential prior exploitation. All workarounds are partial mitigations only and should be treated as temporary bridges to the patched version.