External risk intelligence

n8n-MCP Tenant Data Exposure and Deletion Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.9)

CVE-2026-54052

This is an MCP server for n8n operations. While typically an internal tool for AI assistants, it supports an HTTP mode. If deployed with multi-tenancy enabled and exposed to a network, the service becomes reachable, making the vulnerability exploitable by authenticated tenants.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

An MCP server used by AI assistants for n8n documentation and operations has a critical vulnerability when multi-tenancy is enabled in HTTP mode. This flaw allows authenticated users to access and potentially disrupt workflow data belonging to other tenants. The main concern is confirming if this specific configuration is in use and exposed.

Unauthorized access to tenant workflow data.
Matters if multi-tenancy and HTTP mode are enabled.
Confirming exposure and relevance is the key focus.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this by leveraging the multi-tenancy feature in HTTP mode to access or manipulate workflow backups belonging to other tenants. This could occur if the n8n-MCP server is deployed with multi-tenancy enabled and exposed over a network, allowing an authenticated tenant to view, delete, or corrupt sensitive data from other tenants' backups.

Authenticated tenant access required.
Access to other tenants' backup data.
Unauthorized data access and modification.

Live Threat

Current exploitation, exposure, and threat context

When n8n-MCP is configured in HTTP mode with multi-tenancy enabled, an authenticated tenant could access, delete, or corrupt workflow version history backups belonging to other tenants. This could expose sensitive information such as node definitions, credential references, and authorization headers stored within these backups.

Tenant workflow backup data.
Authenticated tenant could read other tenants' data.
Exposure of sensitive configurations and credentials.

Operational Fix

Recommended remediation, mitigation, and detection steps

The n8n-MCP server, when deployed with multi-tenancy enabled and exposed via HTTP, presents a risk to tenant data isolation. Teams responsible for n8n instances, including platform or infrastructure owners and potentially application owners if n8n is directly integrated into business workflows, should prioritize identifying these deployments. The immediate first step is to confirm the presence and reachability of n8n-MCP instances configured with multi-tenancy, assess their business criticality, and then initiate a risk-based remediation plan.

Identify n8n-MCP deployments with multi-tenancy.
Verify tenant data isolation and reachability.
Plan remediation based on identified risks.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is n8n-MCP and how is it used?

n8n-MCP is an AI Model Context Protocol server. It acts as a bridge, allowing AI assistants to interface directly with n8n workflow platforms by providing access to node documentation, properties, and operational data. Users deploy it to help AI agents understand and interact with their n8n automation environments more effectively.

What does CVE-2026-54052 mean for data security?

This vulnerability is an authorization flaw involving insecure direct object references and missing function-level access control. Because the system fails to isolate workflow backups by tenant, an authenticated user can interact with data that should be private to others. This means a user can read, modify, or delete sensitive snapshots—including credentials and authorization headers—belonging to other tenants on the same server.

When does this vulnerability pose a risk?

The risk is specific to environments running n8n-MCP in HTTP mode with the multi-tenancy feature enabled via the 'ENABLE_MULTI_TENANT' configuration. The bug is not triggered if multi-tenancy is disabled or if the server is running in a different mode. Essentially, the flaw requires the specific multi-tenant HTTP configuration to bypass the necessary logical boundaries between different user groups.

Is my n8n-MCP instance vulnerable according to Halo Surface Signal?

Halo Surface Signal indicates the risk depends on your deployment choices. While n8n-MCP is often used as an internal tool, enabling HTTP mode and multi-tenancy can make it network-reachable. You should care if your instance is deployed in this specific mode and accessible to a broader network, as this allows an authenticated tenant to potentially cross over into other tenants' sensitive workflow backups.

How do I secure my environment against this threat?

Prioritize identifying all active n8n-MCP deployments where multi-tenancy is enabled. Once identified, assess their reachability and business criticality. The definitive step is to update your n8n-MCP software to version 2.56.1 or later, which includes the necessary fixes to restore proper tenant data isolation. Until you can upgrade, consider restricting network access to the server.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.