GHSA-8342-988q-86cr: n8n auth bypass

Q: Is GHSA-8342-988q-86cr actively exploited?

No confirmed active exploitation of GHSA-8342-988q-86cr has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-8342-988q-86cr?

1) Upgrade to n8n 2.32.1 or later — this is the only complete fix. 2) If you cannot patch immediately and use embed login, set N8N_TOKEN_EXCHANGE_ENABLED=false to disable the vulnerable feature entirely. 3) If embed login must stay on, restrict network access to the instance to fully trusted parties and audit every configured trusted key's allowedRoles to ensure role ceilings are correctly scoped. 4) Detection: review auth_identity records for token-exchange entries linked to high-privilege accounts that don't match expected embed-login usage patterns, and monitor logins to admin/high-privilege accounts originating from the token-exchange auth path.

Q: What systems are affected by GHSA-8342-988q-86cr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks.

Q: What is the CVSS score for GHSA-8342-988q-86cr?

No CVSS score has been assigned yet.

CISO Take

n8n, when configured with the embed login feature and at least one trusted key source, will authenticate a user based solely on the email claim inside an externally-issued token — without confirming the issuer actually verified that email or that the trusted key is permitted to impersonate an account with that role. In practice, anyone who can obtain a signed token from a configured trusted issuer that emits unverified emails (a common configuration in embedded SSO setups) can log in as any existing user, including admins, and take full control of the n8n instance. There is no CVSS score, EPSS data, CISA KEV listing, or public exploit/Nuclei template for this issue yet, so there's no evidence of active exploitation, but the impact ceiling is total account takeover on a platform (16 downstream dependents, OpenSSF score 6.6/10) that frequently orchestrates AI agent workflows holding LLM API keys, database credentials, and automation logic. Patch to n8n 2.32.1 immediately if embed login is enabled; if you can't patch now, set N8N_TOKEN_EXCHANGE_ENABLED=false, restrict network access to the instance, and audit every trusted key's allowedRoles plus the auth_identity table for unexpected token-exchange entries tied to high-privilege accounts.

Sources: GitHub Advisory CISA KEV OpenSSF ATLAS

What is the risk?

High severity due to complete authentication bypass and full account takeover, but exploitability is gated: it only applies to instances with the embed login feature enabled and at least one trusted key source configured — not n8n's default configuration. No CVSS vector, EPSS score, CISA KEV listing, public exploit code, or Nuclei template exists yet, indicating no confirmed active exploitation or automated scanning at this time. However, because n8n instances typically hold credentials for downstream AI services (LLM APIs, vector databases, other automation integrations) and orchestrate agentic workflows, an attacker who successfully impersonates a privileged user gains a large blast radius — not just the n8n UI, but everything n8n is credentialed to touch. Organizations running embed login with trusted key sources should treat this as patch-now priority despite the absence of in-the-wild exploitation evidence, given how severe the impact is once the (feature-gated) precondition is met.

How does the attack unfold?

Initial Access

Attacker obtains a validly-signed token from a trusted issuer configured on the n8n instance, one that emits email claims without verifying them.

AML.T0012

Authentication Bypass

Attacker presents the token to n8n's embed login endpoint with an email claim matching a target account; n8n fails to check the trusted key's role ceiling or email verification status.

AML.T0049

Account Takeover

n8n matches the email claim to the existing local account and authenticates the attacker as that user, including potentially an admin.

Impact

Attacker gains full control of the account: access to stored credentials wired into workflows, ability to modify AI agent workflow logic, and a foothold into any connected downstream system.

Initial Access

Attacker obtains a validly-signed token from a trusted issuer configured on the n8n instance, one that emits email claims without verifying them.

AML.T0012

Authentication Bypass

Attacker presents the token to n8n's embed login endpoint with an email claim matching a target account; n8n fails to check the trusted key's role ceiling or email verification status.

AML.T0049

Account Takeover

n8n matches the email claim to the existing local account and authenticates the attacker as that user, including potentially an admin.

Impact

Attacker gains full control of the account: access to stored credentials wired into workflows, ability to modify AI agent workflow logic, and a foothold into any connected downstream system.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.32.0, < 2.32.1	`2.32.1`
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

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Upgrade to n8n 2.32.1 or later — this is the only complete fix. 2) If you cannot patch immediately and use embed login, set N8N_TOKEN_EXCHANGE_ENABLED=false to disable the vulnerable feature entirely. 3) If embed login must stay on, restrict network access to the instance to fully trusted parties and audit every configured trusted key's allowedRoles to ensure role ceilings are correctly scoped. 4) Detection: review auth_identity records for token-exchange entries linked to high-privilege accounts that don't match expected embed-login usage patterns, and monitor logins to admin/high-privilege accounts originating from the token-exchange auth path.

How is it classified?

Auth Bypass Data Leakage Agent Framework AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system access controls

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-8342-988q-86cr?

n8n, when configured with the embed login feature and at least one trusted key source, will authenticate a user based solely on the email claim inside an externally-issued token — without confirming the issuer actually verified that email or that the trusted key is permitted to impersonate an account with that role. In practice, anyone who can obtain a signed token from a configured trusted issuer that emits unverified emails (a common configuration in embedded SSO setups) can log in as any existing user, including admins, and take full control of the n8n instance. There is no CVSS score, EPSS data, CISA KEV listing, or public exploit/Nuclei template for this issue yet, so there's no evidence of active exploitation, but the impact ceiling is total account takeover on a platform (16 downstream dependents, OpenSSF score 6.6/10) that frequently orchestrates AI agent workflows holding LLM API keys, database credentials, and automation logic. Patch to n8n 2.32.1 immediately if embed login is enabled; if you can't patch now, set N8N_TOKEN_EXCHANGE_ENABLED=false, restrict network access to the instance, and audit every trusted key's allowedRoles plus the auth_identity table for unexpected token-exchange entries tied to high-privilege accounts.

Is GHSA-8342-988q-86cr actively exploited?

No confirmed active exploitation of GHSA-8342-988q-86cr has been reported, but organizations should still patch proactively.

How to fix GHSA-8342-988q-86cr?

1) Upgrade to n8n 2.32.1 or later — this is the only complete fix. 2) If you cannot patch immediately and use embed login, set N8N_TOKEN_EXCHANGE_ENABLED=false to disable the vulnerable feature entirely. 3) If embed login must stay on, restrict network access to the instance to fully trusted parties and audit every configured trusted key's allowedRoles to ensure role ceilings are correctly scoped. 4) Detection: review auth_identity records for token-exchange entries linked to high-privilege accounts that don't match expected embed-login usage patterns, and monitor logins to admin/high-privilege accounts originating from the token-exchange auth path.

What systems are affected by GHSA-8342-988q-86cr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks.

What is the CVSS score for GHSA-8342-988q-86cr?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworks

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

## 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.

Exploitation Scenario

An attacker identifies an n8n instance with embed login enabled (common in products that white-label n8n for customer-facing automation). They obtain a validly-signed token from one of the instance's configured trusted issuers — for example an OAuth/OIDC provider that issues tokens with an email claim but doesn't mark it as verified. The attacker sets the email claim to match an existing high-privilege n8n account (e.g., an admin's email, discovered via OSINT or a leaked directory). n8n validates the token's signature, matches the email to the existing local account, and — because it neither checks that the trusted key's allowed role ceiling covers that account nor requires the email claim to be verified — logs the attacker in as that admin. From there the attacker has full account control: they can read or exfiltrate credentials wired into workflows (LLM API keys, database secrets), modify AI agent workflow logic, or pivot into any system the compromised account's workflows touch.

Weaknesses (CWE)

CWE-345 Insufficient Verification of Data Authenticity Primary CWE-863 Incorrect Authorization Primary

CWE-345 — Insufficient Verification of Data Authenticity: The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

Source: MITRE CWE corpus.