CVE-2026-39974: n8n-MCP Server SSRF Vulnerability

CVE-2026-39974 Overview

CVE-2026-39974 is a Server-Side Request Forgery (SSRF) vulnerability affecting n8n-MCP, a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. This vulnerability allows an authenticated attacker holding a valid AUTH_TOKEN to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, enabling attackers to read the contents of any URL the server can reach.

Critical Impact

Attackers can access sensitive cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to, potentially leading to credential theft and lateral movement within cloud environments.

Affected Products

• n8n-MCP versions prior to 2.47.4
• Multi-tenant HTTP installations where multiple operators can present a valid AUTH_TOKEN
• HTTP deployments where tokens are shared with less-trusted clients

Discovery Timeline

• 2026-04-09 - CVE-2026-39974 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-39974

Vulnerability Analysis

This SSRF vulnerability (CWE-918) exists in the multi-tenant HTTP mode of n8n-MCP, where the server processes user-controlled URLs without adequate validation. The flaw allows authenticated users to inject arbitrary destination URLs through HTTP headers, which the server then fetches and returns in JSON-RPC responses. This creates a powerful data exfiltration pathway, particularly dangerous in cloud environments where instance metadata services (IMDS) can be queried to obtain temporary credentials, API keys, and sensitive configuration data.

The vulnerability specifically impacts deployments operating in multi-tenant HTTP mode. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected by this issue.

Root Cause

The root cause is insufficient URL validation in the HTTP server component when processing multi-tenant HTTP headers. The server accepted and processed user-supplied URLs without implementing SSRF protection measures such as URL allowlisting, blocking of internal IP ranges, or restrictions on cloud metadata endpoints. The security patch introduces SSRF validation to reject URLs containing embedded credentials and other potentially malicious patterns.

Attack Vector

An attacker with a valid AUTH_TOKEN can exploit this vulnerability by crafting HTTP requests with malicious URLs in the multi-tenant headers. The server processes these URLs, makes outbound requests to the specified targets, and returns the response content via JSON-RPC. This enables:

1. Cloud Metadata Harvesting - Accessing AWS IMDS (169.254.169.254), GCP, Azure, Alibaba, and Oracle metadata endpoints to steal temporary credentials
2. Internal Service Discovery - Scanning and accessing internal network services not exposed to the internet
3. Data Exfiltration - Reading sensitive data from internal APIs and services

# SSRF-related tests contain literal userinfo URLs (e.g. http://user:pw@host)
# as negative fixtures proving the validator rejects URLs with embedded basic
# auth. These are not real credentials — they're the inputs the code refuses.
tests/unit/utils/ssrf-protection.test.ts
tests/unit/services/n8n-api-client.test.ts
tests/unit/http-server/ssrf-gate.test.ts
tests/unit/flexible-instance-security.test.ts

Source: GitHub Commit Details

Detection Methods for CVE-2026-39974

Indicators of Compromise

• Outbound HTTP requests from the n8n-MCP server to cloud metadata IP addresses (e.g., 169.254.169.254, metadata.google.internal)
• Unusual JSON-RPC responses containing cloud credentials, API keys, or internal service data
• HTTP requests to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) originating from the MCP server
• Anomalous volume of outbound requests from authenticated sessions to diverse internal endpoints

Detection Strategies

• Implement network monitoring to detect outbound connections from n8n-MCP servers to metadata service IP addresses and internal networks
• Review JSON-RPC response logs for sensitive data patterns indicating successful SSRF exploitation
• Deploy egress filtering rules to alert on connections to cloud metadata endpoints from application servers
• Monitor authentication logs for unusual token usage patterns across multiple source IPs

Monitoring Recommendations

• Enable verbose logging on n8n-MCP HTTP server to capture all outbound request destinations
• Configure cloud provider metadata endpoint monitoring (IMDSv2 enforcement on AWS, metadata concealment on GCP)
• Implement network segmentation alerts for unexpected cross-zone communication from MCP servers
• Set up SIEM rules to correlate authentication events with subsequent internal network access attempts

How to Mitigate CVE-2026-39974

Immediate Actions Required

• Upgrade n8n-MCP to version 2.47.4 or later immediately
• Audit AUTH_TOKEN distribution and revoke tokens shared with untrusted parties
• Review network egress rules to restrict outbound connections from n8n-MCP servers
• Enable IMDSv2 on AWS instances or equivalent metadata protection on other cloud platforms
• Examine logs for evidence of SSRF exploitation prior to patching

Patch Information

The vulnerability has been fixed in n8n-MCP version 2.47.4. The patch introduces SSRF protection mechanisms that validate and reject potentially malicious URLs, including those with embedded credentials and requests to restricted destinations.

• Fixed Version:2.47.4
• Patch Commit:d9d847f230923d96e0857ccecf3a4dedcc9b0096
• Release:GitHub Release v2.47.4
• Security Advisory:GHSA-4ggg-h7ph-26qr

Workarounds

• Switch from multi-tenant HTTP mode to single-tenant stdio deployment if immediate patching is not possible
• Implement network-level egress filtering to block access to cloud metadata endpoints and internal networks
• Restrict AUTH_TOKEN access to only trusted operators and implement token rotation
• Deploy a web application firewall (WAF) with SSRF protection rules in front of n8n-MCP servers

# Example: Block metadata endpoint access using iptables
# Run on the n8n-MCP server to prevent SSRF to cloud metadata
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# For AWS: Enforce IMDSv2 to require session tokens
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled