CVE-2026-45707
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk15th percentile - higher than 15% of all known CVEs
Summary
In n8n-MCP prior to 2.51.2, when ENABLE_MULTI_TENANT=true, HTTP requests without x-n8n-url or x-n8n-key headers silently fell back to the operator's credentials, allowing an authenticated MCP tenant to execute n8n management calls against the operator's instance instead of its own.
Risk Assessment
The organization risks unauthorized access to its n8n instance by other tenants, potentially leading to data leakage, configuration changes, or service disruption.
Recommendation
Immediately upgrade n8n-MCP to version 2.51.2 or later. If upgrade is not possible, consider disabling multi-tenant mode (ENABLE_MULTI_TENANT=false) or implementing additional header validation at the proxy level.
Other vulnerabilities in n8n-MCP
See all- CVE-2026-42449High
In versions 2.47.4 through 2.47.13, n8n-MCP has a vulnerability related to the lack of IPv6 address validation in the URL validation function. An attacker can exploit this flaw to send HTTP requests to unauthorized endpoints, leading to data exposure.
- CVE-2026-54052Critical
In n8n-MCP prior to version 2.56.1, in HTTP mode with multi-tenancy enabled (ENABLE_MULTI_TENANT=true), local workflow version history backups were not isolated per tenant. This allowed an authenticated tenant to read and delete backups of other tenants, including full node definitions, credential references, and authorization headers.
- CVE-2026-44694Critical
n8n-MCP, an MCP server, has an authenticated server-side request forgery vulnerability affecting webhook trigger tools and the n8n API client. This issue exists in versions from 2.18.7 to before 2.50.2 and has been patched in version 2.50.2.
- CVE-2026-55608Medium
In n8n-MCP prior to version 2.57.4, multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true could allow an authenticated tenant to access default-scope workflow_versions backups instead of being confined to the tenant scope, exposing or deleting workflow-version backups from prior single-tenant deployments or migrations.
- CVE-2026-45582Medium
In n8n-MCP prior to 2.51.3, the workflow telemetry sanitizer could retain partial fragments of URL-shaped node parameters, such as customer identifiers or secrets in query strings, before sending data to the anonymous telemetry backend. This is fixed in version 2.51.3.
Original NVD description (English source)
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.51.2, when ENABLE_MULTI_TENANT=true, the HTTP transport documents that the target n8n instance is selected per-request from x-n8n-url / x-n8n-key headers. Requests that omitted those headers — or supplied only one of them — silently fell back to the process-level N8N_API_URL / N8N_API_KEY credentials configured for the operator's own n8n instance. As a result, an authenticated MCP tenant could cause n8n management calls to execute against the operator's instance instead of its own. This affects HTTP-mode deployments of n8n-mcp that are run as a shared multi-tenant service. Single-tenant deployments (ENABLE_MULTI_TENANT unset or false) are not affected. This vulnerability is fixed in 2.51.2.