CVE-2026-42449: 
JavaScript vulnerability analysis and mitigation

CVE-2026-42449 is a Server-Side Request Forgery (SSRF) vulnerability in the n8n-mcp npm package, caused by missing IPv6 validation in the synchronous URL validator SSRFProtection.validateUrlSync() used in the SDK embedder path. IPv4-mapped IPv6 addresses (e.g., http://[::ffff:169.254.169.254]) bypass all cloud-metadata, localhost, and private-IP range checks, allowing an attacker who can supply an n8nApiUrl value to force the server to issue HTTP requests to internal resources. It affects n8n-mcp versions v2.47.4 through v2.47.13 and was patched in v2.47.14, published April 22, 2026. The CVSS v3.1 base score is 8.5 (High) (GitHub Advisory, Security Advisory).

The root cause (CWE-918) is that SSRFProtection.validateUrlSync() — the sole SSRF gate in the SDK embedder path (N8NDocumentationMCPServer constructor, getN8nApiClient(), and validateInstanceContext()) — performed only IPv4 range checks and had no logic to detect or reject IPv6 addresses. An attacker supplying a crafted n8nApiUrl containing an IPv4-mapped IPv6 literal such as http://[::ffff:169.254.169.254] (AWS IMDS), ::ffff:127.0.0.1 (localhost), or addresses using 6to4 (2002::/16), NAT64 (64:ff9b::/96), or unique-local (fc00::/7) prefixes would pass validation entirely. The fix in commit 9639f75 introduced a isPrivateOrMappedIpv6() helper gated on net.isIPv6() that blocks all such address classes before the HTTP client is invoked. The first-party HTTP server path was not primarily affected because it uses a separate async validator (validateWebhookUrl) that already caught IPv6 addresses (GitHub Advisory, Patch Commit).

Successful exploitation enables non-blind SSRF: the server fetches the attacker-specified URL and returns the full response body to the caller, allowing exfiltration of cloud instance metadata (AWS IMDS at 169.254.169.254, GCP, Azure, Alibaba, Oracle), data from RFC1918 private networks, and responses from localhost services. Additionally, the n8nApiKey credential is forwarded in the x-n8n-api-key HTTP header to the attacker-controlled target, potentially exposing API keys that could be used for further unauthorized access to the n8n instance. The confidentiality impact is rated High and integrity Low, with no direct availability impact (GitHub Advisory, Security Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.028% (14th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges (the ability to supply a user-controlled n8nApiUrl to the SDK), making it accessible to any authenticated user of an embedding application that accepts such input (GitHub Advisory).

1. Identify a vulnerable deployment: Locate an application embedding n8n-mcp as an SDK (using N8NDocumentationMCPServer or N8NMCPEngine) on versions v2.47.4–v2.47.13 that accepts a user-supplied n8nApiUrl parameter.
2. Craft an IPv4-mapped IPv6 payload: Construct a URL using an IPv4-mapped IPv6 address to target a sensitive internal endpoint, e.g., http://[::ffff:169.254.169.254]/latest/meta-data/ for AWS IMDS, or http://[::ffff:127.0.0.1]:8080/ for a localhost service.
3. Submit the malicious URL: Pass the crafted URL as the n8nApiUrl value in the InstanceContext supplied to N8NDocumentationMCPServer or getN8nApiClient(). The synchronous validator validateUrlSync() will pass the address without rejection.
4. Receive the response: The server issues an HTTP GET request to the internal endpoint and returns the full response body to the caller, exposing cloud metadata (e.g., IAM credentials, instance identity) or internal service data.
5. Harvest leaked credentials: Observe the x-n8n-api-key header forwarded to any attacker-controlled URL specified as n8nApiUrl, capturing the n8n API key for further unauthorized access (GitHub Advisory, Patch Commit).

• Network: Outbound HTTP requests from the n8n-mcp process to 169.254.169.254 (AWS IMDS), metadata.google.internal, 169.254.169.254 (Azure/GCP), or other cloud metadata endpoints; outbound connections to RFC1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or localhost (127.0.0.1) from the n8n-mcp service; HTTP requests with IPv6-literal hostnames in brackets (e.g., [::ffff:x.x.x.x]) in application logs.
• Logs: Application or access logs showing n8nApiUrl values containing bracketed IPv6 literals or IPv4-mapped addresses; HTTP client requests to link-local or loopback addresses originating from the n8n-mcp process.
• Credentials: Unexpected use or appearance of the n8n-api-key value in external or attacker-controlled server logs, indicating the key was forwarded to an unintended destination (GitHub Advisory).

Upgrade to n8n-mcp v2.47.14 or later, which adds IPv6 validation to SSRFProtection.validateUrlSync(). Update via npm with npx n8n-mcp@latest (or pin >= 2.47.14) or Docker with docker pull ghcr.io/czlonkowski/n8n-mcp:latest. If immediate upgrade is not possible: (1) validate n8nApiUrl before passing to the SDK — reject any URL whose hostname is an IP literal (bracketed IPv6 or dotted IPv4) and accept only DNS-resolvable hostnames; (2) restrict egress at the network layer by blocking outbound traffic to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local 169.254.0.0/16, and cloud metadata endpoints; (3) if feasible, derive n8nApiUrl from internal configuration only and do not accept user-controlled values. Network-level egress filtering is recommended as defense-in-depth even after patching (Security Advisory).

The vulnerability was reported by security researcher @manthanghasadiya and the fix was conceived by Romuald Członkowski. The advisory was published by the maintainer on April 22, 2026, and added to the GitHub Advisory Database on April 30, 2026. Coverage appeared on several CVE tracking and threat intelligence platforms shortly after disclosure, including radar.offseq.com and infinitsec.net, and the CVE was noted on Bluesky via automated CVE feeds (GitHub Advisory, Patch Commit).