CVE-2026-45707: CWE-284: Improper Access Control in czlonkowski n8n-mcp
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.51.2, when ENABLE_MULTI_TENANT=true, the HTTP transport documents that the target n8n instance is selected per-request from x-n8n-url / x-n8n-key headers. Requests that omitted those headers — or supplied only one of them — silently fell back to the process-level N8N_API_URL / N8N_API_KEY credentials configured for the operator's own n8n instance. As a result, an authenticated MCP tenant could cause n8n management calls to execute against the operator's instance instead of its own. This affects HTTP-mode deployments of n8n-mcp that are run as a shared multi-tenant service. Single-tenant deployments (ENABLE_MULTI_TENANT unset or false) are not affected. This vulnerability is fixed in 2.51.2.
AI Analysis
Technical Summary
The vulnerability in n8n-mcp (before version 2.51.2) occurs when ENABLE_MULTI_TENANT=true and HTTP requests omit or partially supply the x-n8n-url or x-n8n-key headers. In such cases, the system silently uses the operator's global N8N_API_URL and N8N_API_KEY credentials, enabling an authenticated tenant to perform management operations on the operator's n8n instance rather than their own. This improper access control (CWE-284) affects multi-tenant HTTP-mode deployments, potentially exposing operator-level management capabilities to tenants. The issue is resolved in version 2.51.2.
Potential Impact
An authenticated tenant in a multi-tenant HTTP deployment of n8n-mcp could leverage this vulnerability to execute management calls on the operator's n8n instance, potentially leading to unauthorized access and control over that instance. This could compromise confidentiality and integrity of the operator's n8n environment. Single-tenant deployments are not impacted.
Mitigation Recommendations
Upgrade n8n-mcp to version 2.51.2 or later, where this vulnerability is fixed. No other official remediation or temporary fix is documented. For affected multi-tenant HTTP deployments, applying this update is necessary to prevent unauthorized cross-tenant access. Single-tenant deployments are not affected and require no action.
CVE-2026-45707: CWE-284: Improper Access Control in czlonkowski n8n-mcp
Description
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.51.2, when ENABLE_MULTI_TENANT=true, the HTTP transport documents that the target n8n instance is selected per-request from x-n8n-url / x-n8n-key headers. Requests that omitted those headers — or supplied only one of them — silently fell back to the process-level N8N_API_URL / N8N_API_KEY credentials configured for the operator's own n8n instance. As a result, an authenticated MCP tenant could cause n8n management calls to execute against the operator's instance instead of its own. This affects HTTP-mode deployments of n8n-mcp that are run as a shared multi-tenant service. Single-tenant deployments (ENABLE_MULTI_TENANT unset or false) are not affected. This vulnerability is fixed in 2.51.2.
CVSS v3.1
Score 8.1high
Affected software
pkg:github/czlonkowski/n8n-mcpRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in n8n-mcp (before version 2.51.2) occurs when ENABLE_MULTI_TENANT=true and HTTP requests omit or partially supply the x-n8n-url or x-n8n-key headers. In such cases, the system silently uses the operator's global N8N_API_URL and N8N_API_KEY credentials, enabling an authenticated tenant to perform management operations on the operator's n8n instance rather than their own. This improper access control (CWE-284) affects multi-tenant HTTP-mode deployments, potentially exposing operator-level management capabilities to tenants. The issue is resolved in version 2.51.2.
Potential Impact
An authenticated tenant in a multi-tenant HTTP deployment of n8n-mcp could leverage this vulnerability to execute management calls on the operator's n8n instance, potentially leading to unauthorized access and control over that instance. This could compromise confidentiality and integrity of the operator's n8n environment. Single-tenant deployments are not impacted.
Mitigation Recommendations
Upgrade n8n-mcp to version 2.51.2 or later, where this vulnerability is fixed. No other official remediation or temporary fix is documented. For affected multi-tenant HTTP deployments, applying this update is necessary to prevent unauthorized cross-tenant access. Single-tenant deployments are not affected and require no action.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-05-13T04:38:01.166Z
- Cvss Version
- 3.1
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 6a19993ae29bf47b50eaf581
Added to database: 05/29/2026, 13:48:42 UTC
Last enriched: 06/05/2026, 21:00:26 UTC
Last updated: 07/31/2026, 19:22:59 UTC
Views: 66
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.