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

CVE-2026-55608 Overview

CVE-2026-55608 affects n8n-MCP, a Model Context Protocol (MCP) server that exposes n8n node documentation, properties, and operations to AI assistants. Versions prior to 2.57.4 running in multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true fail to properly isolate tenant scopes. An authenticated tenant can reach default-scope workflow_versions backups instead of being restricted to their own tenant scope. The flaw allows exposure or deletion of workflow-version backups left behind by prior single-tenant deployments or migrations. The issue falls under [CWE-200] Information Exposure and is fixed in version 2.57.4.

Critical Impact
Authenticated tenants in multi-tenant n8n-MCP deployments can read or delete workflow-version backups belonging to the default scope, breaking tenant isolation guarantees.

Affected Products

n8n-MCP versions prior to 2.57.4
Deployments running in multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true
Environments migrated from single-tenant to multi-tenant configurations

Discovery Timeline

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

Technical Details for CVE-2026-55608

Vulnerability Analysis

The vulnerability stems from insufficient scope validation in the handleWorkflowVersions handler when multi-tenant mode is enabled. n8n-MCP resolves an instance scope identifier for each request using tenant headers (x-n8n-url and x-n8n-key). When these headers are missing or partially provided, the resolved scope defaults to an empty string, which corresponds to the default (single-tenant) scope. Authenticated tenants can therefore interact with workflow_versions records stored under the default scope from prior deployments.

The request-validation logic also used incorrect boolean semantics. The pre-patch check required both headers to be absent before rejecting the request, allowing requests that supplied only one header to bypass validation and reach downstream handlers with an empty scope.

Root Cause

Two defects combine to produce the exposure. First, the multi-tenant header check used AND logic (!hasUrl && !hasKey) instead of OR logic, letting partially authenticated requests through. Second, handleWorkflowVersions did not verify that getInstanceScopeId(context) returned a non-empty value before executing workflow-version operations against the shared repository.

Attack Vector

An authenticated tenant sends MCP requests to the workflow-versions handler with missing or partial tenant headers. Because the resolved scope collapses to the default scope, list, read, and delete operations target workflow_versions records that belong to the original single-tenant deployment rather than the caller's tenant.

javascript

// Patch: dist/http-server-single-session.js
                 const headers = extractMultiTenantHeaders(req);
                 const hasUrl = headers['x-n8n-url'];
                 const hasKey = headers['x-n8n-key'];
-                if (process.env.ENABLE_MULTI_TENANT === 'true' && !hasUrl && !hasKey) {
+                if (process.env.ENABLE_MULTI_TENANT === 'true' && (!hasUrl || !hasKey)) {
                     logger_1.logger.warn('Multi-tenant request missing tenant headers', {
-                        hasUrl: false,
-                        hasKey: false
+                        hasUrl: !!hasUrl,
+                        hasKey: !!hasKey
                     });
                     res.status(400).json({
                         jsonrpc: '2.0',

// Patch: dist/mcp/handlers-n8n-manager.js
 async function handleWorkflowVersions(args, repository, context) {
     try {
         const input = workflowVersionsSchema.parse(args);
+        if (process.env.ENABLE_MULTI_TENANT === 'true' && getInstanceScopeId(context) === '') {
+            return {
+                success: false,
+                error: 'Workflow version storage is not available for this tenant context'
+            };
+        }

Source: GitHub commit 1f42899

Detection Methods for CVE-2026-55608

Indicators of Compromise

MCP requests to workflow-version endpoints where only one of x-n8n-url or x-n8n-key is present
Log entries from handleWorkflowVersions executing against an empty instanceScopeId while ENABLE_MULTI_TENANT=true
Unexpected read or delete activity against workflow_versions rows carrying default-scope identifiers after migration to multi-tenant mode

Detection Strategies

Audit n8n-MCP HTTP access logs for JSON-RPC calls invoking workflow_versions modes (list, get, delete) that lack complete tenant header pairs
Correlate application logs showing the warning Multi-tenant request missing tenant headers with subsequent successful workflow-version responses
Compare stored workflow_versions scope identifiers against the active tenant roster to identify orphaned default-scope records still reachable at runtime

Monitoring Recommendations

Enable verbose logging in n8n-MCP and forward events to a centralized log platform for retention and query
Alert on any deletion operation targeting workflow_versions records with an empty or default scope in multi-tenant deployments
Track version drift on the n8n-MCP container image and flag hosts running versions earlier than 2.57.4

How to Mitigate CVE-2026-55608

Immediate Actions Required

Upgrade n8n-MCP to version 2.57.4 or later, as documented in the GitHub Release v2.57.4
Review historical workflow_versions records for evidence of cross-tenant access or unauthorized deletions
Rotate any n8n API keys that may have been exposed through backup contents accessible under the default scope

Patch Information

The fix is delivered in n8n-MCP v2.57.4. It tightens the multi-tenant header validation to reject requests missing either x-n8n-url or x-n8n-key, and adds an explicit guard in handleWorkflowVersions that refuses to operate when getInstanceScopeId(context) returns an empty string under multi-tenant mode. Full technical detail is available in GitHub Security Advisory GHSA-2cf7-hpwf-47h9.

Workarounds

Disable multi-tenant mode by setting ENABLE_MULTI_TENANT=false until the upgrade is applied
Purge or migrate legacy default-scope workflow_versions records before re-enabling multi-tenant mode
Enforce upstream reverse-proxy validation that rejects requests missing either x-n8n-url or x-n8n-key

bash

# Upgrade n8n-MCP container to the patched release
docker pull ghcr.io/czlonkowski/n8n-mcp:2.57.4
docker stop n8n-mcp && docker rm n8n-mcp
docker run -d --name n8n-mcp \
  -e ENABLE_MULTI_TENANT=true \
  -p 3000:3000 \
  ghcr.io/czlonkowski/n8n-mcp:2.57.4