CVE-2026-45707

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.

Upgrade

# NPM
npx n8n-mcp@latest

# Docker
docker pull ghcr.io/czlonkowski/n8n-mcp:latest

Workarounds

If an immediate upgrade is not possible, any one of the following reduces or eliminates exposure:

• Disable multi-tenant mode. Set ENABLE_MULTI_TENANT=false (or unset it) and run a separate n8n-mcp instance per tenant with that tenant's own N8N_API_URL / N8N_API_KEY. This removes the affected code path entirely.
• Reject malformed requests at a proxy. Require both x-n8n-url and x-n8n-key headers on every request and return 400 if either is missing. Neutralizes the primary header-omission path but does not address the secondary response-shape disclosures, so this is a partial mitigation only.
• Reduce the blast radius of the operator API key. If your n8n instance supports API key scoping (Enterprise, or a Community Edition build that exposes scopes), provision the operator's N8N_API_KEY with the minimum scopes required for the operator's own n8n-mcp functions. This does not close the boundary break but limits what a falling-back tenant can do.

Credit

Reported by @u-ktdi.

An authenticated MCP tenant exploiting this path could read and write workflows, executions, data-table contents, and credential metadata on the operator's n8n instance. If the operator's n8n permits Code-node execution that reaches OS-level modules, the path could escalate to remote code execution inside the operator's n8n runtime. The process-level N8N_API_KEY is, in practice, a high-privilege key, Community Edition keys are unscoped by default, and even Enterprise scopes were configured for the operator's own needs and would carry over wholesale to a tenant who triggered the fallback.

CVE-2026-45707 has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.51.2); upgrading removes the vulnerable code path.

Kodem intelligence

Fixed in n8n-mcp 2.51.2. The fix:

• Rejects header-less multi-tenant requests at the HTTP edge with HTTP 400 / JSON-RPC -32602 before any handler runs.
• Refuses to construct an env-credential n8n API client when ENABLE_MULTI_TENANT=true.
• Closes secondary leak paths in trigger handlers and in the responses of n8n_health_check, n8n_diagnostic, n8n_deploy_template, and n8n_audit_instance so the operator's URL and env-key indicator are not surfaced to tenants.

Single-tenant behavior is unchanged.

1. What is CVE-2026-45707? CVE-2026-45707 is a high-severity security vulnerability in n8n-mcp (npm), affecting versions <= 2.51.1. It is fixed in 2.51.2.
2. How severe is CVE-2026-45707? CVE-2026-45707 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of n8n-mcp are affected by CVE-2026-45707? n8n-mcp (npm) versions <= 2.51.1 is affected.
4. Is there a fix for CVE-2026-45707? Yes. CVE-2026-45707 is fixed in 2.51.2. Upgrade to this version or later.
5. Is CVE-2026-45707 exploitable, and should I be worried? Whether CVE-2026-45707 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45707 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45707? Upgrade n8n-mcp to 2.51.2 or later.