Understanding the n8n-MCP Security Flaw
A significant security concern has emerged for users of n8n-MCP, an MCP server designed to give AI assistants access to n8n operations and documentation. This vulnerability, identified as CVE-2026-45707, involves an improper authorization issue that could allow unauthorized access to an operator’s n8n instance in multi-tenant setups. While technical, its implications are straightforward: a tenant could potentially interact with the wrong n8n environment, leading to data exposure or unauthorized actions.
The core of the problem lies in how n8n-MCP handles requests in multi-tenant deployments when the ENABLE_MULTI_TENANT=true setting is active. Normally, requests are directed to a specific n8n instance using special headers (x-n8n-url and x-n8n-key). However, if these headers were missing or incomplete, the system would mistakenly revert to using the main operator’s n8n credentials. This oversight meant an authenticated tenant could inadvertently or maliciously execute commands against the operator’s primary n8n instance, bypassing intended access controls.
It’s crucial to note that this vulnerability specifically impacts HTTP-mode multi-tenant deployments of n8n-mcp. If you run a single-tenant setup (where ENABLE_MULTI_TENANT is not set or set to false), your system is not at risk from this particular flaw.
CVE Details
- Product: n8n-mcp
- Published: May 29, 2026
- Severity: High
- Status: Analyzed
Affected Products
The vulnerability impacts n8n-mcp versions prior to 2.51.2. Specifically, HTTP-mode deployments configured for multi-tenancy (ENABLE_MULTI_TENANT=true) are vulnerable. Older versions running in this configuration are at risk.
Current Status
The vulnerability has been fully analyzed, and a fix is available. The cybersecurity community and the developers of n8n-mcp have addressed this issue, providing a clear path to resolution for affected users.
Severity Level
CVE-2026-45707 is rated with a High severity score of 8.1. A high severity indicates that the vulnerability could lead to significant impact if exploited. In this case, it means an authenticated multi-tenant user could gain unauthorized access to the operator’s n8n instance, potentially leading to data breaches, unauthorized modifications, or service disruption. It’s a serious issue that requires prompt attention.
Possible Solutions
The good news is that a fix is readily available. To protect your n8n-mcp multi-tenant deployment from this vulnerability, you must update to version 2.51.2 or later. This update directly addresses the flaw in instance selection, ensuring that requests from tenants are correctly routed to their designated n8n instances and not the operator’s.
Administrators should:
- Verify their n8n-mcp version.
- Confirm if
ENABLE_MULTI_TENANTis set totruein their HTTP-mode deployment. - Plan and execute an upgrade to n8n-mcp version 2.51.2 or newer as soon as possible.
Regularly updating your software is a fundamental cybersecurity practice. This incident highlights the importance of keeping all components of your infrastructure patched and up-to-date.
References
https://github.com/czlonkowski/n8n-mcp/commit/853015d0897be7cf2d9d4726de195c938e4395ab
https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.51.2
https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-jxx9-px88-pj69

