CVE-2026-39974: 
JavaScript vulnerability analysis and mitigation

CVE-2026-39974 is an authenticated Server-Side Request Forgery (SSRF) vulnerability in n8n-mcp, an npm package providing a Model Context Protocol server for n8n workflow automation. It affects all versions up to and including 2.47.3, and was disclosed on April 8, 2026 by the Eresus Security Research Team (credited to @ibrahmsql). The vulnerability carries a CVSS v3.1 base score of 8.5 (High) (GitHub Advisory, n8n-mcp Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the multi-tenant HTTP mode of n8n-mcp accepts arbitrary URLs supplied via HTTP headers (x-n8n-url and x-n8n-key) without sufficient validation, causing the server to issue outbound HTTP requests to attacker-controlled destinations. An authenticated caller with a valid AUTH_TOKEN can supply any URL through these multi-tenant headers, and the server's response body is reflected back to the caller via JSON-RPC. The fix (commit d9d847f) adds URL validation at entry points and normalizes URLs at the API client layer, introducing a dedicated ssrf-protection utility module (GitHub Advisory, Patch Commit).

An attacker with a valid AUTH_TOKEN can force the n8n-mcp server to make HTTP requests to arbitrary internal or external URLs and receive the full response body through JSON-RPC. This enables exfiltration of sensitive data from cloud instance metadata endpoints (AWS IMDS at 169.254.169.254, GCP, Azure, Alibaba, Oracle), internal network services, and any other host reachable by the server process — potentially exposing cloud credentials, IAM roles, configuration data, and internal service content. The scope change in the CVSS score reflects that the impact extends beyond the vulnerable component itself to other systems on the internal network (GitHub Advisory, n8n-mcp Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of disclosure. The vulnerability requires a valid AUTH_TOKEN, limiting the attack surface to authenticated users or less-trusted clients sharing a token in multi-tenant deployments. The EPSS score is approximately 0.027% (2nd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Obtain a valid AUTH_TOKEN: Acquire a bearer token for the target n8n-mcp multi-tenant HTTP deployment — either through legitimate access, credential theft, or token sharing with less-trusted clients.
2. Identify the target endpoint: Confirm the deployment is running in multi-tenant HTTP mode with ENABLE_MULTI_TENANT set and that the server accepts x-n8n-url and x-n8n-key headers.
3. Craft a malicious JSON-RPC request: Send an authenticated HTTP request to the n8n-mcp server, including the Authorization: Bearer <AUTH_TOKEN> header and setting x-n8n-url to the target internal URL (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/ for AWS IMDS).
4. Receive the reflected response: The server issues an outbound HTTP request to the attacker-specified URL and returns the response body in the JSON-RPC reply, exposing the contents of the internal resource.
5. Pivot to further access: Use harvested cloud credentials or internal service data (e.g., IAM role tokens, internal API keys) to escalate privileges or move laterally within the cloud environment (GitHub Advisory, n8n-mcp Advisory).

• Network: Outbound HTTP requests from the n8n-mcp container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or link-local addresses (169.254.0.0/16, particularly 169.254.169.254 for cloud IMDS); unexpected outbound connections to internal services not normally contacted by the server.
• Logs: HTTP server access logs showing authenticated requests containing x-n8n-url headers with internal or metadata endpoint URLs; JSON-RPC responses containing cloud metadata content (e.g., IAM role names, access key IDs).
• Process/Application: Unusual API client activity in n8n-mcp logs targeting non-standard n8n instance URLs; repeated requests with varying x-n8n-url values from the same AUTH_TOKEN (GitHub Advisory).

Upgrade n8n-mcp to version 2.47.4 or later; no configuration changes are required after upgrading as the fix adds URL validation automatically (Release v2.47.4). If immediate upgrade is not possible, apply the following workarounds: (1) Egress filtering — block outbound traffic from the n8n-mcp container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local 169.254.0.0/16 at the network layer; (2) Disable multi-tenant headers — unset ENABLE_MULTI_TENANT and block x-n8n-url / x-n8n-key headers at the reverse proxy if per-request instance switching is not required; (3) Restrict AUTH_TOKEN distribution — ensure bearer tokens are only held by fully trusted operators (GitHub Advisory, n8n-mcp Advisory).

The vulnerability was reported by the Eresus Security Research Team and credited to @ibrahmsql on GitHub. The advisory was published by the repository maintainer (czlonkowski) on April 8, 2026, and the patch was released the same day. Social media activity was limited, with brief mentions on Bluesky and security aggregator sites shortly after disclosure, but no significant broader community discussion or media coverage has been identified (GitHub Advisory).