CVE-2026-54052: n8n broken tenant isolation leaks

Q: Is CVE-2026-54052 actively exploited?

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

Q: How to fix CVE-2026-54052?

1) Upgrade to n8n-mcp 2.56.1 — the patch isolates version history per tenant and its migration purges previously exposed, un-scoped backups. 2) If immediate upgrade isn't possible, set `DISABLED_TOOLS=n8n_workflow_versions` in the server environment to remove the vulnerable tool while keeping automatic backups running safely. 3) As a structural mitigation, avoid `ENABLE_MULTI_TENANT=true` on shared instances — run one n8n-mcp instance and database per tenant. 4) Restrict network access to the HTTP endpoint to trusted operators only. 5) Detection: audit access logs for the workflow-version-history tool/endpoint for calls referencing workflow or snapshot IDs outside a caller's own tenant scope. 6) Precautionary hygiene: rotate any credentials or authorization headers that were configured on n8n workflow nodes on affected shared instances prior to patching, since historical backups may have already been exposed.

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

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI agent deployments, workflow automation/orchestration pipelines.

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

CVE-2026-54052 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 0.04%.

CISO Take

n8n-mcp, a widely used MCP server that lets AI agents drive n8n workflow automation, failed to isolate the local backup store used for workflow version history in multi-tenant HTTP deployments — meaning any authenticated tenant could read, and even delete, the automatic workflow-update backups belonging to other tenants on the same shared instance. This matters because those snapshots contain full node definitions, including credential references and authorization headers configured on the workflow, so the bug is a direct path to stealing other customers' secrets, not just a logic flaw; the 9.9 CVSS reflects near-complete confidentiality, integrity and availability loss with only low privileges and no user interaction required. It is not in CISA KEV and EPSS sits in the top 87% band rather than near-certain exploitation, and no public exploit or Nuclei template exists yet, but the low bar to exploit (any onboarded tenant, no special tooling) means that's a matter of time rather than a low-risk finding. Patch to n8n-mcp 2.56.1 immediately if you run HTTP mode with `ENABLE_MULTI_TENANT=true` — the upgrade also runs a one-time migration that isolates and purges the previously exposed, un-scoped backups; if you can't patch now, set `DISABLED_TOOLS=n8n_workflow_versions` or split tenants into separate instances/databases, and treat any credentials referenced in workflow nodes on affected shared instances as potentially exposed and rotate them.

Sources: NVD GitHub Advisory CISA KEV EPSS ATLAS

What is the risk?

Critical severity (CVSS 9.9) driven by a low bar to exploit — any authenticated tenant on a shared instance, no user interaction, low attack complexity — combined with high confidentiality and integrity impact and limited availability impact (backup destruction, not full outage). Real-world exploitation risk is currently moderate rather than imminent: EPSS is low (0.00043, ~87th percentile), the flaw is not in CISA KEV, and no public exploit code or Nuclei template exists. However, the vulnerability requires no novel technique — it's a straightforward authorization/tenant-scoping bug (CWE-639/CWE-862) exploitable via ordinary API calls — so exploitation complexity for an already-onboarded malicious or compromised tenant is trivial. The risk is highly configuration-dependent: it only applies to HTTP deployments running with `ENABLE_MULTI_TENANT=true`; stdio and single-tenant HTTP deployments are unaffected.

How does the attack unfold?

Authenticated tenant access

Attacker onboards or already holds low-privilege, legitimate credentials as one tenant on a shared multi-tenant n8n-mcp HTTP instance.

AML.T0012

Tool invocation without tenant scoping

Attacker calls the workflow version-history tool/API, which fails to restrict results to the caller's own tenant due to CWE-639/CWE-862.

AML.T0053

Credential exfiltration

Attacker reads other tenants' workflow snapshots, extracting node definitions containing credential references and authorization headers.

AML.T0086

Data destruction

Attacker optionally deletes other tenants' stored backups, erasing their recovery points and causing an integrity/availability loss.

AML.T0101

Authenticated tenant access

Attacker onboards or already holds low-privilege, legitimate credentials as one tenant on a shared multi-tenant n8n-mcp HTTP instance.

AML.T0012

Tool invocation without tenant scoping

Attacker calls the workflow version-history tool/API, which fails to restrict results to the caller's own tenant due to CWE-639/CWE-862.

AML.T0053

Credential exfiltration

Attacker reads other tenants' workflow snapshots, extracting node definitions containing credential references and authorization headers.

AML.T0086

Data destruction

Attacker optionally deletes other tenants' stored backups, erasing their recovery points and causing an integrity/availability loss.

AML.T0101

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	<= 2.56.0	`2.56.1`
196.1K OpenSSF 6.6 16 dependents Pushed 3d ago 47% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

9.9 / 10

EPSS

0.0%

chance of exploitation in 30 days

Higher than 13% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I High

A Low

What should I do?

1 step

1) Upgrade to n8n-mcp 2.56.1 — the patch isolates version history per tenant and its migration purges previously exposed, un-scoped backups. 2) If immediate upgrade isn't possible, set DISABLED_TOOLS=n8n_workflow_versions in the server environment to remove the vulnerable tool while keeping automatic backups running safely. 3) As a structural mitigation, avoid ENABLE_MULTI_TENANT=true on shared instances — run one n8n-mcp instance and database per tenant. 4) Restrict network access to the HTTP endpoint to trusted operators only. 5) Detection: audit access logs for the workflow-version-history tool/endpoint for calls referencing workflow or snapshot IDs outside a caller's own tenant scope. 6) Precautionary hygiene: rotate any credentials or authorization headers that were configured on n8n workflow nodes on affected shared instances prior to patching, since historical backups may have already been exposed.

How is it classified?

Auth Bypass Data Leakage Privacy Violation Agent Plugin AML.T0053 - AI Agent Tool Invocation AML.T0086 - Exfiltration via AI Agent Tool Invocation AML.T0098 - AI Agent Tool Credential Harvesting AML.T0101 - Data Destruction via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 - Data for AI systems

NIST AI RMF

MANAGE-2.3 - Mechanisms for deactivating or disengaging AI system components

OWASP LLM Top 10

LLM06:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-54052?

n8n-mcp, a widely used MCP server that lets AI agents drive n8n workflow automation, failed to isolate the local backup store used for workflow version history in multi-tenant HTTP deployments — meaning any authenticated tenant could read, and even delete, the automatic workflow-update backups belonging to other tenants on the same shared instance. This matters because those snapshots contain full node definitions, including credential references and authorization headers configured on the workflow, so the bug is a direct path to stealing other customers' secrets, not just a logic flaw; the 9.9 CVSS reflects near-complete confidentiality, integrity and availability loss with only low privileges and no user interaction required. It is not in CISA KEV and EPSS sits in the top 87% band rather than near-certain exploitation, and no public exploit or Nuclei template exists yet, but the low bar to exploit (any onboarded tenant, no special tooling) means that's a matter of time rather than a low-risk finding. Patch to n8n-mcp 2.56.1 immediately if you run HTTP mode with `ENABLE_MULTI_TENANT=true` — the upgrade also runs a one-time migration that isolates and purges the previously exposed, un-scoped backups; if you can't patch now, set `DISABLED_TOOLS=n8n_workflow_versions` or split tenants into separate instances/databases, and treat any credentials referenced in workflow nodes on affected shared instances as potentially exposed and rotate them.

Is CVE-2026-54052 actively exploited?

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

How to fix CVE-2026-54052?

1) Upgrade to n8n-mcp 2.56.1 — the patch isolates version history per tenant and its migration purges previously exposed, un-scoped backups. 2) If immediate upgrade isn't possible, set `DISABLED_TOOLS=n8n_workflow_versions` in the server environment to remove the vulnerable tool while keeping automatic backups running safely. 3) As a structural mitigation, avoid `ENABLE_MULTI_TENANT=true` on shared instances — run one n8n-mcp instance and database per tenant. 4) Restrict network access to the HTTP endpoint to trusted operators only. 5) Detection: audit access logs for the workflow-version-history tool/endpoint for calls referencing workflow or snapshot IDs outside a caller's own tenant scope. 6) Precautionary hygiene: rotate any credentials or authorization headers that were configured on n8n workflow nodes on affected shared instances prior to patching, since historical backups may have already been exposed.

What systems are affected by CVE-2026-54052?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI agent deployments, workflow automation/orchestration pipelines.

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

CVE-2026-54052 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 0.04%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant AI agent deploymentsworkflow automation/orchestration pipelines

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0086 Exfiltration via AI Agent Tool Invocation

AML.T0098 AI Agent Tool Credential Harvesting

AML.T0101 Data Destruction via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM06:2025

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.56.1, in HTTP mode with multi-tenancy enabled through ENABLE_MULTI_TENANT=true, n8n-mcp's local workflow version history backups were not isolated per tenant, allowing an authenticated tenant to read workflow version snapshots belonging to other tenants and delete or destroy other tenants' stored backups, including full node definitions, credential references, and authorization headers. This issue is fixed in version 2.56.1.

Exploitation Scenario

An attacker legitimately signs up as one tenant on a shared, multi-tenant n8n-mcp HTTP deployment (e.g., a SaaS or internal platform wrapping n8n-mcp for multiple business units or customers). Using their own valid low-privilege credentials, they invoke the workflow version-history tool/API but supply or manipulate identifiers referencing snapshots that belong to other tenants; because the local backup store isn't isolated per tenant, the server returns those snapshots. The attacker harvests the full node definitions inside, extracting credential references and authorization headers wired into other tenants' automated workflows (e.g., API keys for connected AI services, cloud providers, or internal systems), then optionally deletes those tenants' backup history to erase recovery points and disrupt their operations.

Weaknesses (CWE)

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

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.