CVE-2026-45707: n8n tenant isolation bypass, operator

Q: Is CVE-2026-45707 actively exploited?

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

Q: How to fix CVE-2026-45707?

1. Patch immediately: upgrade n8n-mcp to 2.51.2 via `npx n8n-mcp@latest` or `docker pull ghcr.io/czlonkowski/n8n-mcp:latest`. 2. If immediate patching is blocked, set ENABLE_MULTI_TENANT=false and run a separate n8n-mcp instance per tenant with that tenant's own credentials — this removes the vulnerable code path entirely. 3. Proxy-level partial mitigation: reject requests missing both x-n8n-url and x-n8n-key headers with HTTP 400; note this only addresses the primary path, not secondary response-shape disclosures. 4. Scope operator API keys: if using n8n Enterprise or a build with API key scoping, provision the operator's N8N_API_KEY with minimum required scopes to limit blast radius should fallback occur. 5. Audit: review n8n execution logs for unexpected workflow triggers, credential reads, or data access patterns originating from tenant sessions prior to patching.

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

This vulnerability affects the following AI/ML architecture patterns: AI agent orchestration, Multi-tenant MCP services, Workflow automation platforms, LLM integration pipelines.

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

CVE-2026-45707 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.24%.

CISO Take

CVE-2026-45707 is a tenant isolation failure in n8n-mcp's HTTP transport: any authenticated MCP tenant can silently pivot to the operator's own n8n instance simply by omitting the x-n8n-url or x-n8n-key request headers, causing all n8n management calls to execute under the operator's high-privilege API key. With a CVSS of 8.1 (High) and no privilege escalation required beyond a valid tenant session, exploitation is trivial for anyone with a legitimate account on a shared n8n-mcp deployment. The blast radius spans full workflow read/write, credential vault metadata, execution history, and data table contents — and escalates to OS-level RCE if the operator's n8n instance permits Code-node execution. Upgrade immediately to n8n-mcp 2.51.2 or, if patching is blocked, disable ENABLE_MULTI_TENANT and deploy isolated per-tenant instances.

Sources: GitHub Advisory NVD OpenSSF ATLAS

What is the risk?

High severity (CVSS 8.1, C:H/I:H). Exploitation requires only a valid tenant credential — no special knowledge, no privilege escalation — making this trivially accessible to any user of a shared n8n-mcp service. Community Edition n8n API keys are unscoped by default, meaning the operator's N8N_API_KEY carries full instance access wholesale. The absence of a public exploit or scanner template provides limited relief given how mechanically simple the attack is (omit two HTTP headers). The potential RCE path via Code-node execution elevates this beyond a data-access event to full operator environment compromise. OpenSSF Scorecard for n8n-mcp is 6.1/10 and 83 prior CVEs exist in the package, suggesting a pattern of security debt.

How does the attack unfold?

Initial Access

Adversary obtains a legitimate tenant account on a shared n8n-mcp HTTP service running with ENABLE_MULTI_TENANT=true.

AML.T0012

Exploitation

Adversary sends MCP HTTP requests omitting x-n8n-url and/or x-n8n-key headers, triggering silent fallback to the operator's process-level N8N_API_URL and N8N_API_KEY.

AML.T0049

Credential Hijack

All subsequent n8n management tool calls execute under the operator's high-privilege API key against the operator's n8n instance, exposing workflows, credential vault, execution history, and data tables.

AML.T0083

Impact

Adversary exfiltrates or modifies operator workflows and credentials; if Code-node execution is enabled, deploys a malicious workflow to achieve RCE within the operator's n8n runtime.

AML.T0086

Initial Access

Adversary obtains a legitimate tenant account on a shared n8n-mcp HTTP service running with ENABLE_MULTI_TENANT=true.

AML.T0012

Exploitation

Adversary sends MCP HTTP requests omitting x-n8n-url and/or x-n8n-key headers, triggering silent fallback to the operator's process-level N8N_API_URL and N8N_API_KEY.

AML.T0049

Credential Hijack

All subsequent n8n management tool calls execute under the operator's high-privilege API key against the operator's n8n instance, exposing workflows, credential vault, execution history, and data tables.

AML.T0083

Impact

Adversary exfiltrates or modifies operator workflows and credentials; if Code-node execution is enabled, deploys a malicious workflow to achieve RCE within the operator's n8n runtime.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
194.3K OpenSSF 6.6 Pushed 6d ago 53% patched ~7d to patch Full package profile →
n8n	npm	<= 2.51.1	`2.51.2`
194.3K OpenSSF 6.6 Pushed 6d ago 53% patched ~7d to patch Full package profile →

How severe is it?

CVSS 3.1

8.1 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 14% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A None

What should I do?

5 steps

Patch immediately: upgrade n8n-mcp to 2.51.2 via npx n8n-mcp@latest or docker pull ghcr.io/czlonkowski/n8n-mcp:latest.
If immediate patching is blocked, set ENABLE_MULTI_TENANT=false and run a separate n8n-mcp instance per tenant with that tenant's own credentials — this removes the vulnerable code path entirely.
Proxy-level partial mitigation: reject requests missing both x-n8n-url and x-n8n-key headers with HTTP 400; note this only addresses the primary path, not secondary response-shape disclosures.
Scope operator API keys: if using n8n Enterprise or a build with API key scoping, provision the operator's N8N_API_KEY with minimum required scopes to limit blast radius should fallback occur.
Audit: review n8n execution logs for unexpected workflow triggers, credential reads, or data access patterns originating from tenant sessions prior to patching.

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 Code Execution Agent Plugin AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0083 - Credentials from AI Agent Configuration AML.T0086 - Exfiltration via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 9 - Risk management system

ISO 42001

6.1.2 - AI risk assessment

NIST AI RMF

GOVERN 1.2 - Accountability and responsibility structures

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-45707?

CVE-2026-45707 is a tenant isolation failure in n8n-mcp's HTTP transport: any authenticated MCP tenant can silently pivot to the operator's own n8n instance simply by omitting the x-n8n-url or x-n8n-key request headers, causing all n8n management calls to execute under the operator's high-privilege API key. With a CVSS of 8.1 (High) and no privilege escalation required beyond a valid tenant session, exploitation is trivial for anyone with a legitimate account on a shared n8n-mcp deployment. The blast radius spans full workflow read/write, credential vault metadata, execution history, and data table contents — and escalates to OS-level RCE if the operator's n8n instance permits Code-node execution. Upgrade immediately to n8n-mcp 2.51.2 or, if patching is blocked, disable ENABLE_MULTI_TENANT and deploy isolated per-tenant instances.

Is CVE-2026-45707 actively exploited?

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

How to fix CVE-2026-45707?

1. Patch immediately: upgrade n8n-mcp to 2.51.2 via `npx n8n-mcp@latest` or `docker pull ghcr.io/czlonkowski/n8n-mcp:latest`. 2. If immediate patching is blocked, set ENABLE_MULTI_TENANT=false and run a separate n8n-mcp instance per tenant with that tenant's own credentials — this removes the vulnerable code path entirely. 3. Proxy-level partial mitigation: reject requests missing both x-n8n-url and x-n8n-key headers with HTTP 400; note this only addresses the primary path, not secondary response-shape disclosures. 4. Scope operator API keys: if using n8n Enterprise or a build with API key scoping, provision the operator's N8N_API_KEY with minimum required scopes to limit blast radius should fallback occur. 5. Audit: review n8n execution logs for unexpected workflow triggers, credential reads, or data access patterns originating from tenant sessions prior to patching.

What systems are affected by CVE-2026-45707?

This vulnerability affects the following AI/ML architecture patterns: AI agent orchestration, Multi-tenant MCP services, Workflow automation platforms, LLM integration pipelines.

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

CVE-2026-45707 has a CVSS v3.1 base score of 8.1 (HIGH). The EPSS exploitation probability is 0.24%.

What is the AI security impact?

Affected AI Architectures

AI agent orchestrationMulti-tenant MCP servicesWorkflow automation platformsLLM integration pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0083 Credentials from AI Agent Configuration

AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Art. 9

ISO 42001: 6.1.2

NIST AI RMF: GOVERN 1.2

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.51.2, when ENABLE_MULTI_TENANT=true, the HTTP transport documents that the target n8n instance is selected per-request from x-n8n-url / x-n8n-key headers. Requests that omitted those headers — or supplied only one of them — silently fell back to the process-level N8N_API_URL / N8N_API_KEY credentials configured for the operator's own n8n instance. As a result, an authenticated MCP tenant could cause n8n management calls to execute against the operator's instance instead of its own. This affects HTTP-mode deployments of n8n-mcp that are run as a shared multi-tenant service. Single-tenant deployments (ENABLE_MULTI_TENANT unset or false) are not affected. This vulnerability is fixed in 2.51.2.

Exploitation Scenario

An adversary registers as a legitimate tenant on a shared n8n-mcp HTTP service (ENABLE_MULTI_TENANT=true). They craft MCP HTTP requests deliberately omitting the x-n8n-url and x-n8n-key headers. The unpatched server receives header-incomplete requests and silently falls back to the operator's process-level N8N_API_URL and N8N_API_KEY. All subsequent n8n management calls execute against the operator's n8n instance — the adversary enumerates all workflows, reads stored credential metadata (LLM API keys, SaaS OAuth tokens, database passwords), and exfiltrates execution history. If Code-node execution is enabled with OS-level module access, the adversary deploys a malicious workflow containing a Node.js Code node that spawns a reverse shell, achieving persistent RCE in the operator's environment with no additional steps.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary CWE-284 Improper Access Control Primary CWE-284 Improper Access Control

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.