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

CVE-2026-54052 has a CVSS 3.1 base score of 9.9 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L. EPSS exploitation probability: 0.4%.

Which versions of n8n-mcp are affected by CVE-2026-54052?

n8n-mcp versions 2.56.0 and earlier enable cross-tenant access to workflow backups on shared deployments, exposing other customers' credentials and sensitive data to unauthorized access and deletion.. A patch is available.

How to fix or mitigate CVE-2026-54052?

Within 24 hours, identify all production deployments of n8n-mcp version 2.56.0 or earlier, inventory which customer tenants share HTTP instances, and begin reviewing access logs and backup modification timestamps for evidence of cross-tenant access. Within 7 days, implement immediate compensating controls by segregating multi-tenant instances, restricting backup access by tenant identity at the application level, rotating any embedded credentials in workflows, and disabling automatic version backups if operationally feasible. Within 30 days, establish continuous monitoring for n8n-mcp security advisories and vendor patches; deploy any released patch immediately upon validation in a staging environment; consider architectural redesign to eliminate shared tenancy or migrate to single-tenant deployments if business requirements permit.

n8n-mcp CVE-2026-54052

CRITICAL

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-07-14 https://github.com/czlonkowski/n8n-mcp

GHSA-j6r7-6fhx-77wx

Authentication Bypass Docker

9.9

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.9 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

vuln.today AI

9.9 CRITICAL

Authenticated tenant (PR:L) reaches other tenants' data over the network, crossing a trust boundary (S:C) with high confidentiality/integrity and only low availability impact (backups destroyed, service intact).

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Source Code Evidence Fetched

Jul 14, 2026 - 20:21 vuln.today

Analysis Generated

Jul 14, 2026 - 20:21 vuln.today

CVE Published

Jul 14, 2026 - 19:07 github-advisory

CRITICAL 9.9

DescriptionNVD

Impact

In multi-tenant HTTP deployments - where a single n8n-mcp server serves several tenants - the locally stored workflow version history (the automatic backups taken before workflow updates) was not isolated per tenant. An authenticated tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants' stored backups.

A stored snapshot includes full node definitions, so the exposed data can contain credential references and authorization headers configured on nodes. This is therefore a confidentiality issue in addition to an integrity/availability one.

Affected configurations

HTTP mode with multi-tenancy enabled (ENABLE_MULTI_TENANT=true), where multiple tenants are served by a single shared instance and database.

Not affected:

stdio / single-user deployments (e.g. Claude Desktop).
Single-tenant HTTP deployments (one tenant per instance and database).

Affected versions

<= 2.56.0

Patched version

2.56.1. The stored version history is now isolated per instance, so a tenant can only access its own backups. Upgrading runs a one-time migration that isolates existing history and clears previously stored, un-scoped backups (these are auto-created, short-retention backups).

Workarounds

If users cannot upgrade immediately:

Disable the workflow version tool by setting DISABLED_TOOLS=n8n_workflow_versions in the server environment (for example, in your Docker .env). This removes the affected tool from the deployment for all tenants; automatic backups are unaffected, but the cross-tenant access path is closed.
Alternatively, do not run in multi-tenant mode - serve each tenant from a separate instance with its own database, so no local store is shared between tenants.
Restrict network access to the HTTP endpoint to trusted operators.

stdio and single-tenant HTTP deployments are not affected.

Credit

Reported by Francisco Rosales (@0xmagic0) and coordinated by Ax Sharma (@axsharma) of Manifold Security.

Articles & Coverage 1

News Critical Cross-Tenant Data Exposure in Docker - CVE-2026-54052 Jul 15, 2026

AnalysisAI

Cross-tenant data exposure in n8n-mcp (npm package, <= 2.56.0) lets an authenticated tenant on a shared multi-tenant HTTP instance read, delete, and destroy the automatic workflow version backups belonging to other tenants. Because each snapshot embeds full node definitions, the leaked data can include credential references and authorization headers, making this both a confidentiality and an integrity/availability failure. Rated CVSS 9.9 due to the scope change across tenant trust boundaries; no public exploit is identified at time of analysis, and it is not listed in CISA KEV.

Technical ContextAI

n8n-mcp is a Model Context Protocol (MCP) server that bridges LLM agents (e.g. Claude) to the n8n workflow-automation platform. In HTTP mode with ENABLE_MULTI_TENANT=true, a single process and database serve multiple tenants. Before every workflow update the server auto-creates a version snapshot (a short-retention backup) in a locally stored version history. The root cause maps to CWE-639 (Authorization Bypass Through User-Controlled Key / insecure direct object reference): the stored version history was keyed and queried without an instance/tenant scope, so lookups and deletions were not constrained to the caller's own tenant. The vendor fix (commit ced57ab) scopes workflow_versions per instance and adds a one-time migration that isolates existing history and purges previously un-scoped backups.

RemediationAI

Vendor-released patch: 2.56.1 - upgrade to n8n-mcp 2.56.1, which isolates version history per instance and runs a one-time migration that isolates existing history and clears previously stored un-scoped backups (auto-created, short-retention data, so the purge is low impact). Pull the fixed images ghcr.io/czlonkowski/n8n-mcp:v2.56.1 or ghcr.io/czlonkowski/n8n-mcp-railway:v2.56.1, or install n8n-mcp@2.56.1 from npm. If you cannot upgrade immediately, disable the affected tool by setting DISABLED_TOOLS=n8n_workflow_versions in the server environment (e.g. in the Docker .env); this closes the cross-tenant access path for all tenants and leaves automatic backups themselves intact, at the cost of removing the version-history tool. Alternatively, stop running multi-tenant mode and serve each tenant from a separate instance with its own database so no local store is shared, and restrict network access to the HTTP endpoint to trusted operators. References: release notes https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.56.1 and advisory https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-j6r7-6fhx-77wx.