CVE-2026-42449
HighSummary
In versions 2.47.4 through 2.47.13, n8n-MCP has a vulnerability related to the lack of IPv6 address validation in the URL validation function. An attacker can exploit this flaw to send HTTP requests to unauthorized endpoints, leading to data exposure.
Risk Assessment
Organizations may be exposed to SSRF attacks that could result in data leakage from local services or private networks. The exposure of the n8n API key may allow attackers to perform further actions within the system.
Recommendation
It is recommended to update n8n-MCP to the latest version that includes fixes for IPv6 address validation. Additionally, access to n8nApiUrl in applications using this server should be reviewed and restricted.
Other vulnerabilities in n8n-MCP
See all- CVE-2026-54052Critical
In n8n-MCP prior to version 2.56.1, in HTTP mode with multi-tenancy enabled (ENABLE_MULTI_TENANT=true), local workflow version history backups were not isolated per tenant. This allowed an authenticated tenant to read and delete backups of other tenants, including full node definitions, credential references, and authorization headers.
- CVE-2026-44694Critical
n8n-MCP, an MCP server, has an authenticated server-side request forgery vulnerability affecting webhook trigger tools and the n8n API client. This issue exists in versions from 2.18.7 to before 2.50.2 and has been patched in version 2.50.2.
- CVE-2026-55608Medium
In n8n-MCP prior to version 2.57.4, multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true could allow an authenticated tenant to access default-scope workflow_versions backups instead of being confined to the tenant scope, exposing or deleting workflow-version backups from prior single-tenant deployments or migrations.
- CVE-2026-45707High
In n8n-MCP prior to 2.51.2, when ENABLE_MULTI_TENANT=true, HTTP requests without x-n8n-url or x-n8n-key headers silently fell back to the operator's credentials, allowing an authenticated MCP tenant to execute n8n management calls against the operator's instance instead of its own.
- CVE-2026-45582Medium
In n8n-MCP prior to 2.51.3, the workflow telemetry sanitizer could retain partial fragments of URL-shaped node parameters, such as customer identifiers or secrets in query strings, before sending data to the anonymous telemetry backend. This is fixed in version 2.51.3.
Original NVD description (English source)
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. In versions 2.47.4 through 2.47.13, the SDK embedder path (N8NDocumentationMCPServer constructor, getN8nApiClient(), and validateInstanceContext()), the synchronous URL validator in SSRFProtection.validateUrlSync() had no IPv6 checks. IPv4-mapped IPv6 addresses such as http://[::ffff:169.254.169.254] bypassed the cloud-metadata, localhost, and private-IP range checks. An attacker able to supply an n8nApiUrl value could cause the server to issue HTTP requests to cloud metadata endpoints, RFC1918 private networks, or localhost services. Response bodies are returned to the caller (non-blind SSRF), and the n8nApiKey is forwarded in the x-n8n-api-key header to the attacker-controlled target. Projects with deployments embedding n8n-mcp as an SDK using N8NDocumentationMCPServer or N8NMCPEngine with user-supplied InstanceContext are affected. The first-party HTTP server deployment