Back to Advisories
ERESUS-ADV-2026-004CriticalCVSS: 8.6

Zero-Day Analysis: Authenticated SSRF in n8n-mcp (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.

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.

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 doesn't strict 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.