CVE-2026-42227: n8n IDOR leaks cross-project

Q: Is CVE-2026-42227 actively exploited?

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

Q: How to fix CVE-2026-42227?

1. IMMEDIATE: Upgrade to n8n 1.123.32 (v1 branch), 2.17.4, or 2.18.1 (v2 branch) — patches enforce project membership checks in the variables handler. 2. IMMEDIATE if patching is delayed: Audit all n8n variables for stored credentials or tokens and rotate any that may have been exposed, prioritizing LLM API keys, cloud provider credentials, and database connection strings. 3. Audit existing API key assignments and revoke variable:list scope from users who do not explicitly require it. 4. Review API access logs for anomalous GET requests to the /variables endpoint containing projectId values outside the requesting user's known project memberships. 5. Long-term: Migrate sensitive credentials out of n8n variables into a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or equivalent) and reference them by reference rather than storing values directly in workflow variables.

Q: What systems are affected by CVE-2026-42227?

This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, AI workflow orchestration, Multi-tenant AI platforms, LLM API integration pipelines.

Q: What is the CVSS score for CVE-2026-42227?

No CVSS score has been assigned yet.

CISO Take

n8n enterprise and team deployments expose an Insecure Direct Object Reference (IDOR) flaw where any authenticated user holding a variable:list-scoped API key can read variables from any project in the instance by supplying an arbitrary projectId parameter — no project membership required, no elevated privilege needed. The root cause is a direct repository query that bypasses the authorization-aware service layer entirely, meaning multi-tenant isolation collapses silently at the API level. Although the absolute EPSS probability is low (0.0003), this CVE sits in the top 91st percentile for exploitation likelihood among all published vulnerabilities, and with 75 historical CVEs in the same package and a package risk score of 69/100, n8n is a persistent weak link in AI workflow automation stacks. If variables were used to store LLM API keys, database credentials, OAuth tokens, or webhook secrets — a common anti-pattern in workflow tools — rotate them immediately and upgrade to 1.123.32, 2.17.4, or 2.18.1.

Sources: NVD GitHub Advisory EPSS ATLAS OpenSSF

What is the risk?

MEDIUM-HIGH for multi-project enterprise and team n8n deployments. Exploitation requires only a valid API key with variable:list scope, achievable by any registered user, insider threat, or attacker who has compromised any team member's API key. The authorization bypass is trivial — a single modified HTTP parameter — and the impact scales directly with how sensitive the stored variables are. Single-project deployments and personal cloud instances are unaffected, which limits blast radius but does not reduce per-deployment severity. The absence of a public exploit and CISA KEV listing tempers immediate urgency, but the trivial exploitation path combined with potential credential exposure in AI workflow pipelines elevates this above a typical IDOR finding.

How does the attack unfold?

Initial Access

Attacker obtains a valid n8n API key with variable:list scope — as an insider, via phishing a team member, or from an exposed key in a code repository or config file.

AML.T0012

Authorization Bypass

Attacker queries the /variables public API endpoint with arbitrary projectId values; the handler skips project membership validation and returns variable data for any project ID supplied.

AML.T0049

Credential Harvesting

Attacker iterates projectId values across the instance, collecting LLM API keys, OAuth tokens, database credentials, and webhook secrets stored in other teams' project variables.

AML.T0083

Impact

Harvested credentials are used to access LLM provider APIs under victim billing accounts, exfiltrate data from connected AI pipelines and vector databases, or pivot into cloud infrastructure hosting those AI workloads.

AML.T0055

Initial Access

Attacker obtains a valid n8n API key with variable:list scope — as an insider, via phishing a team member, or from an exposed key in a code repository or config file.

AML.T0012

Authorization Bypass

Attacker queries the /variables public API endpoint with arbitrary projectId values; the handler skips project membership validation and returns variable data for any project ID supplied.

AML.T0049

Credential Harvesting

Attacker iterates projectId values across the instance, collecting LLM API keys, OAuth tokens, database credentials, and webhook secrets stored in other teams' project variables.

AML.T0083

Impact

Harvested credentials are used to access LLM provider APIs under victim billing accounts, exfiltrate data from connected AI pipelines and vector databases, or pivot into cloud infrastructure hosting those AI workloads.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.32	`1.123.32`
193.4K OpenSSF 6.6 Pushed 4d ago 54% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.2%

chance of exploitation in 30 days

Higher than 10% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

5 steps

IMMEDIATE

Upgrade to n8n 1.123.32 (v1 branch), 2.17.4, or 2.18.1 (v2 branch) — patches enforce project membership checks in the variables handler.
IMMEDIATE if patching is delayed: Audit all n8n variables for stored credentials or tokens and rotate any that may have been exposed, prioritizing LLM API keys, cloud provider credentials, and database connection strings.
Audit existing API key assignments and revoke variable:list scope from users who do not explicitly require it.
Review API access logs for anomalous GET requests to the /variables endpoint containing projectId values outside the requesting user's known project memberships.
Long-term: Migrate sensitive credentials out of n8n variables into a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or equivalent) and reference them by reference rather than storing values directly in workflow variables.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass Data Extraction Agent API AML.T0012 - Valid Accounts AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration AML.T0085 - Data from AI Services

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.9 - Risk management system

ISO 42001

A.6.1.2 - Segregation of duties A.9.4 - System and application access control

NIST AI RMF

GOVERN 1.2 - Accountability and authorization structures

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-42227?

n8n enterprise and team deployments expose an Insecure Direct Object Reference (IDOR) flaw where any authenticated user holding a variable:list-scoped API key can read variables from any project in the instance by supplying an arbitrary projectId parameter — no project membership required, no elevated privilege needed. The root cause is a direct repository query that bypasses the authorization-aware service layer entirely, meaning multi-tenant isolation collapses silently at the API level. Although the absolute EPSS probability is low (0.0003), this CVE sits in the top 91st percentile for exploitation likelihood among all published vulnerabilities, and with 75 historical CVEs in the same package and a package risk score of 69/100, n8n is a persistent weak link in AI workflow automation stacks. If variables were used to store LLM API keys, database credentials, OAuth tokens, or webhook secrets — a common anti-pattern in workflow tools — rotate them immediately and upgrade to 1.123.32, 2.17.4, or 2.18.1.

Is CVE-2026-42227 actively exploited?

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

How to fix CVE-2026-42227?

1. IMMEDIATE: Upgrade to n8n 1.123.32 (v1 branch), 2.17.4, or 2.18.1 (v2 branch) — patches enforce project membership checks in the variables handler. 2. IMMEDIATE if patching is delayed: Audit all n8n variables for stored credentials or tokens and rotate any that may have been exposed, prioritizing LLM API keys, cloud provider credentials, and database connection strings. 3. Audit existing API key assignments and revoke variable:list scope from users who do not explicitly require it. 4. Review API access logs for anomalous GET requests to the /variables endpoint containing projectId values outside the requesting user's known project memberships. 5. Long-term: Migrate sensitive credentials out of n8n variables into a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, or equivalent) and reference them by reference rather than storing values directly in workflow variables.

What systems are affected by CVE-2026-42227?

This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, AI workflow orchestration, Multi-tenant AI platforms, LLM API integration pipelines.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Agent frameworksAI workflow orchestrationMulti-tenant AI platformsLLM API integration pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

AML.T0085 Data from AI Services

Compliance Controls Affected

EU AI Act: Art.9

ISO 42001: A.6.1.2, A.9.4

NIST AI RMF: GOVERN 1.2

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to versions 1.123.32, 2.17.4, and 2.18.1, an authenticated user with a valid API key scoped to variable:list could read variables from projects they are not a member of by supplying an arbitrary projectId query parameter to the public API variables endpoint. The handler queried the variables repository directly without enforcing project membership checks, bypassing the authorization-aware service layer used by the internal enterprise controller. If variables were misused to store sensitive information such as credentials or tokens, they should be rotated immediately. This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled. This issue has been patched in versions 1.123.32, 2.17.4, and 2.18.1.

Exploitation Scenario

An insider threat or attacker who has phished or compromised a team member's n8n API key — even one scoped only to variable:list — iterates through sequential or enumerated projectId values against the /variables public API endpoint. For each project, the handler returns the full variable payload without validating membership, exposing API keys for LLM providers, OAuth tokens, database URIs, and webhook secrets belonging to other teams. The attacker uses harvested LLM API keys to exfiltrate model outputs or consume quota under the victim's billing account, uses database credentials to access training data or vector stores connected to AI pipelines, and uses cloud provider credentials to pivot laterally into infrastructure hosting those AI workloads — all without triggering alerts tied to the legitimate API key holder.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.