Listen to this Post
When `ENABLE_MULTI_TENANT=true` is set, the HTTP transport documentation states that the target n8n instance is selected per-request using the `x-n8n-url` and `x-n8n-key` headers. However, requests that omit both headers—or supply only one of them—silently fall back to the process-level `N8N_API_URL` and `N8N_API_KEY` credentials configured for the operator‘s own n8n instance. This fallback behavior allows an authenticated MCP tenant to cause n8n management calls to execute against the operator’s instance instead of its own. The vulnerability only affects HTTP‑mode deployments that are run as a shared multi‑tenant service; single‑tenant deployments (with `ENABLE_MULTI_TENANT` unset or set to false) are not impacted. An exploiting tenant can read and write workflows, executions, data‑table contents, and credential metadata on the operator’s n8n instance. If the operator‘s n8n instance permits Code‑node execution that reaches OS‑level modules, the path can escalate to remote code execution inside the operator’s n8n runtime. The process‑level `N8N_API_KEY` is effectively 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 triggers the fallback. The vulnerability is 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, and closes secondary leak paths in various handlers so the operator‘s URL and env‑key indicator are not surfaced to tenants.
dailycve form:
Platform: n8n-mcp
Version: ≤ 2.51.1
Vulnerability: Header omission fallback
Severity: Critical
date: 2026-05-08
Prediction: Patched 2026-05-10
What Undercode Say:
Upgrade to patched version via npx npx n8n-mcp@latest Upgrade via Docker docker pull ghcr.io/czlonkowski/n8n-mcp:latest Disable multi-tenant mode (workaround) ENABLE_MULTI_TENANT=false Reject incomplete requests at proxy (partial mitigation) if [ -z "$http_x_n8n_url" ] || [ -z "$http_x_n8n_key" ]; then return 400; fi
Exploit:
An authenticated MCP tenant sends a request to the `/mcp` endpoint without including the `x-n8n-url` and `x-n8n-key` headers. The n8n-mcp server, instead of rejecting the malformed request, falls back to using the operator‘s own `N8N_API_URL` and N8N_API_KEY. This allows the tenant to perform any n8n management action (e.g., list workflows, modify executions, read credentials) against the operator’s instance, bypassing the tenant isolation intended by the multi‑tenant design.
Protection from this CVE
- Upgrade to n8n‑mcp 2.51.2 or later.
- Set `ENABLE_MULTI_TENANT=false` and run a separate instance per tenant.
- Configure a reverse proxy to require both `x-n8n-url` and `x-n8n-key` headers on every request and return HTTP 400 if either is missing (partial mitigation).
- Scope the operator‘s `N8N_API_KEY` to the minimum necessary permissions to limit damage if a fallback occurs.
Impact:
- Read/write workflows, executions, data‑table contents, and credential metadata on the operator’s n8n instance.
- Potential remote code execution inside the operator’s n8n runtime if Code‑node execution is allowed.
- Complete breakdown of multi‑tenant isolation, allowing one tenant to compromise the operator’s instance.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
