n8n-mcp Authenticated SSRF: Affected Versions, Patch, and Exposure Review (CVE-2026-39974)

Introduction

Yiğit İbrahim Sağlam (@ibrahmsql) has successfully identified and reported an Authenticated Server-Side Request Forgery (SSRF) vulnerability in n8n-mcp (Model Context Protocol). This vulnerability is tracked under the GitHub Security Advisory GHSA-4ggg-h7ph-26qr.

n8n-mcp provides Model Context Protocol servers for the popular n8n workflow automation tool. The vulnerability specifically affects multi-tenant HTTP deployments, allowing an authenticated user to bypass network restrictions and query internal endpoints.

The Vulnerability Explained

In a multi-tenant HTTP deployment configuration, n8n-mcp relies on request headers (x-n8n-url and x-n8n-key) to identify which target n8n instance to route queries to.

However, in versions up to 2.47.3, the server lacked proper validation on the x-n8n-url header. This allowed an attacker holding a valid AUTH_TOKEN to manipulate the instance URL and force the server to issue HTTP requests to arbitrary URLs.

Because the response bodies are seamlessly reflected back through JSON-RPC to the caller, the attacker could effectively read the contents of any URL reachable by the server process.

Severity and impact context

GitHub Advisory Database identifies this issue as CVE-2026-39974, High, CVSS v3.1 8.5. It affects n8n-mcp versions through 2.47.3; 2.47.4 is patched. The primary at-risk configuration is multi-tenant HTTP where a caller has a valid AUTH_TOKEN; single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.

The server can be made to request arbitrary URLs and return response bodies. Access to cloud metadata or internal data depends on network reachability and caller access; the advisory does not claim credential exposure in every affected deployment.

Remediation and Mitigation

Following our report, the maintainers quickly addressed the issue by adding strict validation at the URL entry points and normalizing URLs at the API client layer.

1. Upgrade Immediately (Recommended)

The vulnerability is fully patched in n8n-mcp version 2.47.4. Users must upgrade their instances immediately. No structural configuration changes are required for the upgrade itself.

2. Network-Layer Defense (Workaround)

If upgrading is not immediately feasible, you should implement strict egress filtering. Block outbound traffic from the n8n-mcp container/server to link-local addresses and internal networks:

• 169.254.0.0/16
• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

3. Disable Multi-Tenant Capabilities

If your architecture does not strictly require per-request instance switching, unset the ENABLE_MULTI_TENANT variable and strip any x-n8n-url and x-n8n-key headers at your reverse proxy (NGINX/Traefik) before they reach the main service.

Conclusion

This finding underscores the hidden dangers of dynamic URL parsing in multi-tenant architectures. We want to thank the n8n-mcp maintainers for their swift triage and professional response in coordinating this fix.

For continuous vulnerability research, pentesting, and DevSecOps engineering, keep following the Eresus Security blog.

Exposure validation without exploit traffic

Start with inventory and configuration rather than probing arbitrary internal URLs. Confirm the installed version, whether HTTP multi-tenant mode is enabled, whether a shared AUTH_TOKEN is used, and whether the service can reach metadata or private network ranges. Single-tenant stdio deployments and HTTP deployments without the affected multi-tenant headers are described as outside the primary affected scope in the advisory.

Review proxy behavior as well. The reverse proxy should strip client-supplied routing headers, enforce authentication, restrict outbound destinations, and preserve the original caller identity. Container egress policy should deny link-local metadata and unnecessary private ranges, while allowing documented service dependencies.

Detection and response

Search logs for requests that contain unexpected instance-routing headers, destinations outside the approved n8n inventory, unusual JSON-RPC response sizes, and access from identities that do not normally use the service. If exposure is confirmed, rotate the service token, review reachable cloud and internal systems, preserve logs, and rebuild from a patched image. Patching alone does not revoke credentials that may already have been used.

Frequently asked questions

Does a valid token make the issue low severity?

No. Authentication limits who can reach the path, but the server may still be able to read sensitive internal resources. Severity depends on token distribution, network reachability, and exposed data.

Is blocking metadata IPs sufficient?

It reduces one impact path. It does not fix URL validation, internal service access, token compromise, or unsafe proxy behavior. Upgrade and apply layered egress controls.