CVE-2026-45707 Overview
CVE-2026-45707 is a broken access control vulnerability [CWE-284] in n8n-MCP, a Model Context Protocol (MCP) server that exposes n8n node documentation, properties, and operations to AI assistants. In multi-tenant HTTP deployments (ENABLE_MULTI_TENANT=true), requests that omitted the x-n8n-url or x-n8n-key headers silently fell back to the operator's process-level N8N_API_URL and N8N_API_KEY credentials. An authenticated tenant could therefore route n8n management calls to the operator's own n8n instance instead of its tenant-scoped target. The flaw affects versions prior to 2.51.2 and is fixed in 2.51.2.
Critical Impact
Authenticated tenants on shared n8n-MCP HTTP deployments can execute n8n management operations against the operator's privileged instance, breaking tenant isolation.
Affected Products
- n8n-MCP HTTP-mode deployments running as a shared multi-tenant service
- All n8n-MCP versions prior to 2.51.2 with ENABLE_MULTI_TENANT=true
- Deployments configuring process-level N8N_API_URL / N8N_API_KEY as operator credentials
Discovery Timeline
- 2026-05-29 - CVE-2026-45707 published to NVD
- 2026-06-01 - Last updated in NVD database
Technical Details for CVE-2026-45707
Vulnerability Analysis
n8n-MCP's HTTP transport supports a multi-tenant mode where each request selects its target n8n instance via the x-n8n-url and x-n8n-key headers. The documented contract assumes that every tenant request will supply both headers. The implementation, however, did not enforce this contract. When either header was missing, the server resolved the n8n target by falling back to the environment-level N8N_API_URL and N8N_API_KEY variables.
Those process-level variables typically hold the operator's own n8n credentials, used for local testing or administrative bootstrapping. As a result, authenticated tenants could invoke n8n management tools against the operator's privileged instance. The vulnerability is scoped to HTTP-mode multi-tenant deployments. Single-tenant installations, or deployments where ENABLE_MULTI_TENANT is unset or false, are not affected.
Root Cause
The root cause is a permissive credential resolution path in the HTTP request handler. The handler treated tenant headers as optional inputs rather than mandatory per-request credentials. Missing or partial headers were not rejected; instead the server reused operator credentials, violating tenant isolation. This pattern maps to CWE-284 (Improper Access Control), where authorization boundaries are not enforced at the credential-selection layer.
Attack Vector
An attacker requires authenticated tenant access to the shared n8n-MCP HTTP endpoint. The attacker issues an MCP tool request that omits one or both of the x-n8n-url and x-n8n-key headers. The server resolves the call against the operator's n8n instance and executes any n8n management operation exposed through MCP. Operations may include workflow enumeration, credential retrieval through workflows, workflow execution, and modification of automation logic on the operator's environment.
No verified public exploit code is available. The fix is implemented in commit 853015d and described in the GitHub Security Advisory GHSA-jxx9-px88-pj69.
Detection Methods for CVE-2026-45707
Indicators of Compromise
- HTTP requests to the n8n-MCP server missing x-n8n-url or x-n8n-key headers while ENABLE_MULTI_TENANT=true is configured.
- n8n audit logs on the operator instance showing API calls originating from the n8n-MCP service account at times correlated with tenant activity.
- Unexpected workflow executions, credential reads, or workflow modifications on the operator's n8n instance.
- n8n-MCP versions prior to 2.51.2 deployed in HTTP transport mode.
Detection Strategies
- Inspect reverse proxy and application logs for MCP tool calls that lack tenant headers but still produced successful n8n responses.
- Correlate n8n API request source IPs and timestamps against tenant identity records to identify cross-tenant access patterns.
- Alert on any n8n management API call made by the operator's API key during a tenant-initiated MCP session.
Monitoring Recommendations
- Enable verbose request logging on the n8n-MCP HTTP layer to capture header presence per request.
- Forward n8n audit events and MCP server logs to a centralized SIEM for correlation across tenants.
- Track the deployed n8n-MCP version across hosts and alert when any instance running below 2.51.2 has multi-tenant mode enabled.
How to Mitigate CVE-2026-45707
Immediate Actions Required
- Upgrade n8n-MCP to version 2.51.2 or later on all HTTP-mode multi-tenant deployments.
- Rotate the operator's N8N_API_KEY if multi-tenant mode was enabled on a vulnerable build.
- Audit the operator n8n instance for unauthorized workflow changes, credential access, and executions occurring before the upgrade.
- Restrict tenant authentication tokens until the upgrade is verified.
Patch Information
The fix is shipped in n8n-MCP v2.51.2. The patch enforces presence of both x-n8n-url and x-n8n-key headers per request in multi-tenant mode and removes the fallback to process-level credentials. Technical details are available in the security advisory GHSA-jxx9-px88-pj69.
Workarounds
- Set ENABLE_MULTI_TENANT=false and operate the n8n-MCP server as a single-tenant service until the upgrade is applied.
- Remove N8N_API_URL and N8N_API_KEY from the n8n-MCP process environment so missing-header requests fail closed.
- Place a reverse proxy in front of n8n-MCP that rejects requests lacking both x-n8n-url and x-n8n-key headers.
# Configuration example: disable the vulnerable fallback path
unset N8N_API_URL
unset N8N_API_KEY
export ENABLE_MULTI_TENANT=false
# Then upgrade to the fixed release
npm install n8n-mcp@2.51.2
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
