CVE-2026-45707: n8n-MCP Multi-Tenant Privilege Escalation (CVSS 8.1 HIGH)

Technical summary

The vulnerability exists in n8n-mcp's HTTP transport layer when ENABLE_MULTI_TENANT=true. The specification documents that per-request tenant selection is controlled via x-n8n-url and x-n8n-key headers. However, requests omitting both headers, or providing only one, silently default to process-level N8N_API_URL and N8N_API_KEY environment variables—which point to the operator's own n8n instance, not the tenant's. This creates a privilege escalation and lateral movement path: an authenticated tenant user can craft requests without (or with incomplete) tenant-identification headers to invoke n8n management operations against the operator's instance. The flaw is in implicit fallback behavior rather than explicit multi-tenancy bypass; it represents improper trust-boundary enforcement between tenant contexts. Single-tenant deployments (ENABLE_MULTI_TENANT unset or false) are unaffected because they do not activate the multi-tenant code path.

Business impact

For operators running n8n-mcp as a shared multi-tenant SaaS or internal platform service, compromise of the operator's primary n8n instance can lead to full administrative takeover: unauthorized workflow modification, credential theft, lateral movement into connected integrations, and potential data exfiltration. Tenants may gain access to workflows, credentials, and execution history belonging to other tenants or the operator itself. Regulatory exposure includes data isolation violations and breach notification obligations. Customer trust and platform reputation suffer immediately. Incident response complexity is high because the operator must determine the scope of cross-tenant lateral movement and reset all shared credentials.

Affected systems

n8n-mcp versions prior to 2.51.2 in HTTP-mode deployments with ENABLE_MULTI_TENANT=true. This affects operators who have explicitly enabled multi-tenancy and exposed n8n-mcp to multiple authenticated users or tenant accounts. Organizations using single-tenant configurations, or those who have not set ENABLE_MULTI_TENANT=true, are not vulnerable. The vulnerability requires network access to the n8n-mcp HTTP endpoint and valid authentication credentials for at least one tenant account.

Exploitability

Exploitation is straightforward for an authenticated tenant user: craft an HTTP request to n8n-mcp without the x-n8n-url and x-n8n-key headers (or with only one), and the request will route to the operator's instance. No special exploit code or zero-day techniques are required. The barrier to entry is low—only valid tenant authentication is needed. However, discovery requires either documentation reading or trial-and-error probing. The vulnerability is not listed in the NVD's Known Exploited Vulnerabilities (KEV) catalog as of the data provided, suggesting either recent disclosure or limited real-world exploitation visibility at the time of publication.

Remediation

Operators must upgrade n8n-mcp to version 2.51.2 or later immediately. The fix enforces strict validation of tenant-identification headers: requests without both x-n8n-url and x-n8n-key will be rejected rather than silently falling back to operator credentials. After patching, verify the configuration and test tenant isolation by confirming that incomplete header requests fail gracefully. If an operator suspects prior exploitation, audit n8n execution logs for cross-tenant or unusual administrative operations and reset all operator and tenant API keys.

Patch guidance

Deploy n8n-mcp 2.51.2 as soon as possible. Before upgrading, review your deployment's ENABLE_MULTI_TENANT setting: if it is false or unset, the risk is eliminated but the patch should still be applied to prevent future misconfiguration. Test the patched version in a staging environment to confirm that tenant-isolation enforcement does not break legitimate multi-tenant request flows. Ensure that your monitoring and alerting detect any 400/401 errors related to missing tenant headers post-patch, as legitimate client code may need adjustment. Verify vendor advisories for any additional context or breaking changes.

Detection guidance

Monitor n8n-mcp HTTP request logs for requests to multi-tenant endpoints that lack one or both of x-n8n-url and x-n8n-key headers, especially if they arrive from authenticated users. Correlate these requests with n8n execution logs on the operator's primary instance for unexpected administrative operations (workflow modifications, credential access, user management). Review audit logs for API key usage that originates from tenant accounts but affects the operator's instance or other tenants. Set alerting for authentication mismatches between the requesting tenant context and the target instance. Network-level detection is difficult because the flaw is in application logic; focus on log aggregation and behavioral anomaly detection.

Why prioritize this

A CVSS 3.1 score of 8.1 (HIGH) reflects the severity: the vulnerability requires low barrier to exploitation (authenticated access only), affects confidentiality and integrity equally, and is present in the application's core multi-tenancy logic. While single-tenant deployments are safe, any operator offering multi-tenant n8n-mcp must treat this as critical. The lack of KEV listing does not reduce urgency; this is a clear privilege escalation in a management plane. Prioritize this vulnerability above other n8n-MCP issues and patch within your critical vulnerability SLA (ideally within 48–72 hours for production).

Risk score, explained

CVSS 3.1/8.1/HIGH is justified by: (1) Network Attack Vector (AV:N): the flaw is triggered via HTTP requests, not requiring local or physical access; (2) Low Attack Complexity (AC:L): no special conditions or race conditions required; (3) Low Privilege Requirement (PR:L): an authenticated tenant user is sufficient; (4) No User Interaction (UI:N): the attack is automated; (5) Unchanged Scope (S:U): the operator's instance and other tenants are in the same trust boundary, so this is not a scope change; (6) High Confidentiality and Integrity Impact (C:H, I:H): an attacker can read and modify operator-level data and workflows; (7) No Availability Impact (A:N): the flaw does not enable denial-of-service. The score correctly penalizes a multi-tenant architecture flaw with wide blast radius.

Frequently asked questions