n8n-mcp Authenticated SSRF: CVE-2026-39974 (GHSA-4ggg-h7ph-26qr)
Disclosed: 2026-04-09
Introduction
Our Eresus Security Research Team member (@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 lists CVE-2026-39974 as High, CVSS v3.1 8.5. The issue affects n8n-mcp versions through 2.47.3; 2.47.4 is the patched version. Severity is not a statement that every deployment has the same exposure: the advisory identifies multi-tenant HTTP deployments with valid AUTH_TOKEN access as the primary risk, while single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.
The SSRF can make the server request arbitrary URLs and return response bodies to the caller. Whether that exposes cloud metadata or internal data depends on the server's reachable network and the credentials available to the caller; the advisory does not establish that every affected deployment has exposed credentials.
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/1610.0.0.0/8172.16.0.0/12192.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.
Related Services