CVE-2026-44694: N8n-mcp Server SSRF Vulnerability

CVE-2026-44694 Overview

CVE-2026-44694 is an authenticated server-side request forgery (SSRF) vulnerability in n8n-MCP, an MCP server that exposes n8n node documentation, properties, and operations to AI assistants. The flaw affects releases from version 2.18.7 up to but not including version 2.50.2. Vulnerable code paths include the webhook trigger tools, the n8n API client configured through N8N_API_URL, and per-request URLs supplied via the x-n8n-url header when running in multi-tenant HTTP mode. An authenticated attacker can coerce the server into issuing arbitrary outbound requests to internal services. The maintainer released a fix in version 2.50.2.

Critical Impact

Authenticated users can pivot through n8n-MCP to reach internal network resources, cloud metadata endpoints, and other non-public services, exposing confidential data and enabling lateral movement.

Affected Products

• n8n-MCP 2.18.7 through versions earlier than 2.50.2
• Deployments configuring N8N_API_URL for the n8n API client
• Multi-tenant HTTP mode deployments accepting the x-n8n-url request header

Discovery Timeline

• 2026-05-08 - CVE-2026-44694 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-44694

Vulnerability Analysis

The vulnerability is a server-side request forgery affecting three outbound request surfaces inside n8n-MCP. The webhook trigger tools accept caller-influenced URLs and dispatch HTTP requests from the server. The n8n API client honors the N8N_API_URL configuration without sufficient destination validation. In multi-tenant HTTP mode, the x-n8n-url header lets an authenticated tenant override the upstream target on a per-request basis. Because the requests originate from the n8n-MCP process, they inherit network reachability to internal subnets, link-local cloud metadata services, and other hosts unreachable from the public internet. The advisory classifies the weakness under [CWE-367], reflecting time-of-check to time-of-use semantics around URL handling rather than a single validation gap.

Root Cause

The n8n API client constructs its base URL and version probes from caller-controlled configuration. The upstream fix in commit bcaba83 adds a pinnedAgentsPromise and a getPinnedAgents helper to pin and reuse a validated upstream identity, preventing later requests from being redirected to attacker-chosen destinations.

Attack Vector

An authenticated user with access to the MCP interface or the multi-tenant HTTP endpoint submits a webhook trigger or sets the x-n8n-url header to an internal address. The server performs the outbound request and returns response data to the caller, enabling reconnaissance and data retrieval against internal services.

     private baseUrl;
     private versionInfo;
     private versionPromise;
+    private pinnedAgentsPromise;
     constructor(config: N8nApiClientConfig);
+    private getPinnedAgents;
     getVersion(): Promise<N8nVersionInfo | null>;
     private fetchVersionOnce;
     getCachedVersionInfo(): N8nVersionInfo | null;

Source: GitHub Commit bcaba83. The patch introduces a pinned-agent cache so that the resolved upstream cannot be silently swapped between the version check and subsequent requests.

Detection Methods for CVE-2026-44694

Indicators of Compromise

• Outbound HTTP requests from the n8n-MCP host to RFC1918 addresses, 127.0.0.0/8, or 169.254.169.254 cloud metadata endpoints.
• Inbound requests containing the x-n8n-url header pointing to non-public destinations.
• Webhook trigger invocations targeting hostnames that do not match the configured N8N_API_URL.

Detection Strategies

• Inspect reverse proxy and load balancer logs for x-n8n-url header values that resolve to internal IP ranges.
• Compare process-level egress destinations from the n8n-MCP service against an allowlist derived from documented n8n endpoints.
• Alert on n8n-MCP requests to cloud instance metadata services, including IMDSv1 and IMDSv2 endpoints.

Monitoring Recommendations

• Forward application and proxy logs to a centralized analytics platform and correlate outbound URLs with caller identity.
• Enable DNS query logging on the n8n-MCP host to surface lookups for internal hostnames originating from the service.
• Track the deployed n8n-MCP version against 2.50.2 across all tenants and environments.

How to Mitigate CVE-2026-44694

Immediate Actions Required

• Upgrade n8n-MCP to version 2.50.2 or later, which contains the fix from commit bcaba83.
• Audit existing N8N_API_URL configurations and confirm they reference only intended n8n control planes.
• Restrict who can authenticate to the MCP server and the multi-tenant HTTP endpoint, removing dormant credentials.

Patch Information

The patch is available in the GitHub Release v2.50.2 and described in the GitHub Security Advisory GHSA-cmrh-wvq6-wm9r. The underlying code change is in GitHub Commit bcaba83.

Workarounds

• Place n8n-MCP behind an egress proxy that blocks requests to RFC1918, loopback, and cloud metadata addresses until upgrade.
• Strip the x-n8n-url header at the edge for tenants that do not require per-request overrides.
• Disable multi-tenant HTTP mode if a single trusted upstream can be enforced through N8N_API_URL.

# Example egress restriction enforced at the host firewall
iptables -A OUTPUT -m owner --uid-owner n8nmcp -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner n8nmcp -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner n8nmcp -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner n8nmcp -d 192.168.0.0/16 -j REJECT