CVE-2026-45707
Authentication Bypass in n8n-MCP via Missing Tenant Headers
Publication date: 2026-05-29
Last updated on: 2026-05-29
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| czlonkowski | n8n-mcp | to 2.51.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-45707 is a vulnerability in the n8n-mcp package affecting versions 2.51.1 and earlier when multi-tenant mode is enabled (ENABLE_MULTI_TENANT=true). The system fails to properly validate tenant-specific headers (x-n8n-url and x-n8n-key) in HTTP requests. If these headers are missing or incomplete, the system silently falls back to using process-level credentials (N8N_API_URL and N8N_API_KEY) configured for the operator's n8n instance.
This flaw allows an authenticated MCP tenant to execute management operations on the operator's n8n instance instead of their own, potentially leading to unauthorized access to workflows, executions, data tables, and credential metadata. In some cases, this could escalate to remote code execution within the operator's environment if the operator's n8n permits Code-node execution with OS-level access.
The vulnerability was fixed in version 2.51.2 by rejecting header-less multi-tenant requests at the HTTP edge with a 400 error before any processing occurs.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows an authenticated MCP tenant to execute management operations on the operator's n8n instance instead of their own, potentially leading to unauthorized access to workflows, executions, data tables, and credential metadata.
Such unauthorized access could result in exposure or manipulation of sensitive data, which may violate data protection requirements under standards like GDPR or HIPAA that mandate strict controls on data confidentiality and integrity.
Additionally, if the operator's n8n instance permits code-node execution with OS-level access, this vulnerability could escalate to remote code execution, further increasing the risk of data breaches and non-compliance with regulatory requirements.
Therefore, until patched, this vulnerability poses a significant risk to compliance with common data protection standards by undermining access controls and potentially exposing sensitive information.
How can this vulnerability impact me? :
This vulnerability can have serious impacts if you are using n8n-mcp in multi-tenant mode. An authenticated tenant could perform management operations on the operator's n8n instance instead of their own.
- Unauthorized access to workflows, executions, data tables, and credential metadata belonging to the operator.
- Potential escalation to remote code execution within the operator's environment if Code-node execution with OS-level access is permitted.
These impacts compromise confidentiality and integrity of the operator's n8n instance and can lead to significant security breaches.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring HTTP requests to the n8n-mcp server for missing or incomplete tenant-specific headers (x-n8n-url and x-n8n-key). Requests that omit these headers or supply only one of them may indicate attempts to exploit the fallback to process-level credentials.
To detect such requests on your network or system, you can use network monitoring or HTTP logging tools to filter for requests to the n8n-mcp HTTP endpoint that lack either the x-n8n-url or x-n8n-key headers.
Example commands to detect such requests might include:
- Using tcpdump to capture HTTP traffic and filter for missing headers is complex, but you can capture traffic on the relevant port (e.g., 80 or 443): tcpdump -i eth0 -A 'tcp port 80'
- Using grep on HTTP access logs to find requests missing the x-n8n-url or x-n8n-key headers, for example: grep -L 'x-n8n-url' /var/log/nginx/access.log or grep -L 'x-n8n-key' /var/log/nginx/access.log
- Using a proxy or web application firewall (WAF) to enforce and log requests missing these headers.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Upgrade n8n-mcp to version 2.51.2 or later, where the vulnerability is fixed by rejecting header-less multi-tenant requests with a 400 error.
- If upgrading is not immediately possible, disable multi-tenant mode by setting ENABLE_MULTI_TENANT to false or unset.
- Enforce validation of the x-n8n-url and x-n8n-key headers at a proxy or firewall level to block requests missing these headers.
- Reduce the privileges of the operator's API key (N8N_API_KEY) to limit potential damage if fallback occurs.