Zero-Day Analysis: Authenticated SSRF in n8n-mcp (GHSA-4ggg-h7ph-26qr)

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.

Impact and Attack Scenarios

The implications of this SSRF are severe for environments deployed on public clouds or corporate networks:

1. Cloud Metadata Exfiltration: The attacker could query AWS IMDS (169.254.169.254), GCP, Azure, or Alibaba Cloud metadata endpoints, successfully extracting sensitive cloud credentials and network configurations.
2. Internal Network Scanning: The SSRF could be weaponized to map the internal network (RFC1918 ranges) and identify hidden internal services, APIs, and databases.
3. Data Breach: Reflection of sensitive internal resources could lead to direct exposure of proprietary source code or PII data.

Note: Single-tenant stdio deployments and HTTP deployments that do not utilize multi-tenant headers are not affected.

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.