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-mcp container 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 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_TENANT and do not accept x-n8n-url / x-n8n-key headers at the reverse proxy.
- Restrict
AUTH_TOKEN distribution — 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
References
ibrahmsql Reporter
Impact
An authenticated Server-Side Request Forgery in
n8n-mcpallows a caller holding a validAUTH_TOKENto 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-mcp2.47.4and later.Workarounds
If you cannot immediately upgrade:
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.ENABLE_MULTI_TENANTand do not acceptx-n8n-url/x-n8n-keyheaders at the reverse proxy.AUTH_TOKENdistribution — ensure the bearer token is only held by fully trusted operators until you can upgrade.Remediation
Upgrade to
n8n-mcp2.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
References