CVE-2026-54052: n8n-MCP Information Disclosure Flaw

CVE-2026-54052 Overview

CVE-2026-54052 is a critical authorization flaw in n8n-MCP, a Model Context Protocol (MCP) server that gives AI assistants access to n8n node documentation, properties, and operations. In HTTP mode with ENABLE_MULTI_TENANT=true, the server fails to isolate local workflow version history backups per tenant. An authenticated tenant can read workflow version snapshots owned by other tenants and delete or destroy their stored backups. Exposed data includes full node definitions, credential references, and authorization headers. The issue is fixed in version 2.56.1 and classified under CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact
Authenticated tenants can read, alter, and destroy other tenants' workflow backups, exposing credential references and authorization headers stored inside workflow snapshots.

Affected Products

n8n-MCP versions prior to 2.56.1
Deployments running HTTP mode with ENABLE_MULTI_TENANT=true
Multi-tenant n8n-MCP instances storing local workflow version history

Discovery Timeline

2026-07-15 - CVE-2026-54052 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-54052

Vulnerability Analysis

n8n-MCP acts as an MCP server that exposes n8n workflow tooling to AI assistants. When operators enable multi-tenancy through the ENABLE_MULTI_TENANT=true environment variable in HTTP mode, the server is expected to segregate persisted state so that each tenant only sees its own data. The workflow version history subsystem stores local backup snapshots of workflows, including their node graph, embedded credential references, and any authorization headers configured for HTTP-based nodes.

Before version 2.56.1, these version history backups were written to a shared location and served without a tenant scope check. Any authenticated tenant issuing requests against the backup endpoints could enumerate and retrieve snapshots belonging to other tenants. The same lack of scoping applied to write and delete operations, allowing tenants to remove or corrupt other tenants' historical backups. The Exploit Prediction Scoring System (EPSS) probability is 0.389% at the 31.15 percentile.

Root Cause

The root cause is a missing authorization check on a user-controllable identifier used to key workflow version history records, aligning with [CWE-639]. The backup storage layer trusted the request's workflow or snapshot identifier without verifying that the identifier belonged to the requesting tenant. Multi-tenant isolation was assumed at the request routing layer but not enforced at the persistence layer.

Attack Vector

An attacker only needs a valid tenant account on a vulnerable n8n-MCP HTTP deployment. From that account, the attacker calls the workflow version history endpoints using identifiers belonging to another tenant. The server returns the requested snapshot content, or performs the requested destructive action, without verifying ownership. Because workflow snapshots frequently embed credential references and static authorization headers, a successful read can hand the attacker material to pivot into third-party APIs integrated by the victim tenant. See the GitHub Security Advisory GHSA-j6r7-6fhx-77wx for the maintainer's technical write-up.

No verified public exploit code is available. The vulnerability mechanism is documented in prose only.

Detection Methods for CVE-2026-54052

Indicators of Compromise

HTTP access log entries showing one tenant identity requesting workflow version history paths tied to another tenant's workflow IDs.
Unexpected deletions or modifications of workflow version snapshots that do not correlate with any legitimate tenant admin action.
Outbound requests from n8n integrations using authorization headers that originated in another tenant's workflow definitions.

Detection Strategies

Correlate authenticated tenant identifiers with the workflow or snapshot IDs they access, and alert on cross-tenant identifier access patterns.
Enable audit logging on the n8n-MCP HTTP endpoints and forward the events to a SIEM for behavioral analysis.
Baseline normal workflow backup read and delete rates per tenant, then flag statistically anomalous spikes.

Monitoring Recommendations

Monitor the running n8n-MCP version and alert when any host runs a build older than 2.56.1.
Track credential and authorization header usage across tenants to detect reuse of leaked secrets.
Watch for unauthorized deletions in the workflow version history store and preserve immutable off-host backups.

How to Mitigate CVE-2026-54052

Immediate Actions Required

Upgrade n8n-MCP to version 2.56.1 or later on every HTTP-mode multi-tenant deployment.
Rotate all credentials and authorization headers referenced in workflows that may have been exposed to other tenants.
Review workflow version history for unauthorized reads, deletions, or modifications since multi-tenancy was enabled.

Patch Information

The fix is available in n8n-MCP 2.56.1. See the GitHub Release v2.56.1 notes and the coordinated GHSA-j6r7-6fhx-77wx advisory for maintainer guidance. The release enforces per-tenant scoping on workflow version history operations.

Workarounds

Disable multi-tenancy by setting ENABLE_MULTI_TENANT=false and running one n8n-MCP instance per tenant until patching is complete.
Restrict HTTP-mode access to trusted operators only, using network controls or an authenticating reverse proxy.
Temporarily disable or prune the local workflow version history feature if the deployment cannot be upgraded immediately.

bash

# Configuration example: pin n8n-MCP to the fixed release
# docker-compose.yml fragment
services:
  n8n-mcp:
    image: ghcr.io/czlonkowski/n8n-mcp:2.56.1
    environment:
      - ENABLE_MULTI_TENANT=true
      - MCP_MODE=http
    restart: unless-stopped