EUVD-2026-20968
GHSA-4ggg-h7ph-26qr
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Lifecycle Timeline
5DescriptionGitHub Advisory
Impact
An authenticated Server-Side Request Forgery in n8n-mcp allows a caller 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, so an attacker can read the contents of any URL the server can reach - including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server process has network access to.
The primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid AUTH_TOKEN, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.
Affected versions
n8n-mcp ≤ 2.47.3 (all versions up to and including 2.47.3).
Patched versions
n8n-mcp 2.47.4 and later.
Workarounds
If you cannot immediately upgrade:
- Egress filtering at the network layer - block outbound traffic from the
n8n-mcpcontainer to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local169.254.0.0/16, and any other internal ranges. This defends against any future SSRF-class issue and is recommended even after upgrading. - Disable multi-tenant headers - if your deployment does not require per-request instance switching, unset
ENABLE_MULTI_TENANTand do not acceptx-n8n-url/x-n8n-keyheaders at the reverse proxy. - Restrict
AUTH_TOKENdistribution - ensure the bearer token is only held by fully trusted operators until you can upgrade.
Remediation
Upgrade to n8n-mcp 2.47.4 or later. No configuration changes are required; the fix adds validation at the URL entry points and normalizes URLs at the API client layer.
Credits
Reported by the Eresus Security Research Team. @ibrahmsql
AnalysisAI
Server-Side Request Forgery in n8n-mcp (npm package) versions ≤2.47.3 allows authenticated attackers with valid AUTH_TOKEN to force the server to issue HTTP requests to arbitrary URLs via manipulated multi-tenant HTTP headers (x-n8n-url, x-n8n-key). Response bodies are reflected through JSON-RPC, enabling unauthorized access to cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Oracle, Alibaba), internal network services, and any host reachable by the server process. Multi-tenant HTTP deployments with shared or multiple AUTH_TOKENs are at highest risk. No public exploit identified at time of analysis.
Technical ContextAI
CWE-918 SSRF arises from insufficient validation of user-controlled URLs passed through multi-tenant HTTP headers before server-issued requests. The vulnerability permits URL reflection in JSON-RPC responses, enabling metadata exfiltration. Patch 2.47.4 implements URL entry-point validation and client-layer normalization. Single-tenant stdio deployments remain unaffected.
RemediationAI
Vendor-released patch: upgrade to n8n-mcp version 2.47.4 or later; no configuration changes required. If immediate upgrade is not feasible, implement network-layer egress filtering to block outbound traffic to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local 169.254.0.0/16, and cloud metadata endpoints. Disable ENABLE_MULTI_TENANT flag and reject x-n8n-url/x-n8n-key headers at reverse proxy if multi-tenant functionality is unnecessary. Restrict AUTH_TOKEN distribution to fully trusted operators only. Official advisory and patch details: https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-4ggg-h7ph-26qr and commit https://github.com/czlonkowski/n8n-mcp/commit/d9d847f230923d96e0857ccecf3a4dedcc9b0096
Same weakness CWE-918 – Server-Side Request Forgery (SSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today