n8n-MCP Multi-Tenant Header Omission Vulnerability Allowing Operator API Access

A vulnerability in n8n-MCP versions prior to 2.51.2 allows authenticated MCP tenants to unintentionally access the operator's n8n instance instead of their own. This issue arises when 'ENABLE_MULTI_TENANT' is set to true and requests to the n8n API lack the necessary 'x-n8n-url' and 'x-n8n-key' headers'. In such cases, the request defaults to using the operator's process-level n8n API credentials, potentially leading to unauthorized management actions on the operator's n8n instance. The vulnerability is present in HTTP-mode deployments of n8n-MCP that are shared multi-tenant services, while single-tenant deployments are not affected.

Impact

Exploitation of this vulnerability allows an authenticated MCP tenant to perform n8n management actions on the operator's instance. This includes reading and writing workflows, accessing execution data, and managing credential metadata. If the operator's n8n instance permits Code-node execution that interacts with OS-level modules, this could escalate to remote code execution within the operator's n8n environment.

Reproduction

To reproduce this vulnerability, deploy n8n-MCP in a shared multi-tenant HTTP mode with 'ENABLE_MULTI_TENANT' set to true. An authenticated MCP tenant can then send a request to the n8n API without the 'x-n8n-url' or 'x-n8n-key' headers'. The absence of these headers will trigger a fallback to the operator's process-level n8n API credentials, allowing the tenant to execute management actions on the operator's n8n instance.

Remediation

Upgrade to n8n-MCP version 2.51.2 or later. If an immediate upgrade is not possible, consider disabling multi-tenant mode or rejecting requests without the required tenant headers at a proxy.