[HIGH] Security Advisory: n8n-mcp has authenticated SSRF via instance-URL header in multi-tenant HTTP mode (n8n-mcp)

n8n-mcp, a component that enables multi-instance support for the n8n workflow automation tool, has a serious authenticated Server-Side Request Forgery (SSRF) vulnerability in versions up to 2.47.3. Attackers with a valid AUTH_TOKEN can supply arbitrary URLs through multi-tenant HTTP headers like x-n8n-url, forcing the server to fetch them and return the full response bodies via JSON-RPC. This hits hardest in multi-tenant setups where multiple operators share access or tokens leak to less-trusted clients.

The flaw lets attackers read any resource the n8n-mcp server process can reach. Think cloud metadata services: AWS IMDS at 169.254.169.254, GCP at metadata.google.internal, Azure at 169.254.169.254/metadata, Alibaba, Oracle—all ripe for picking if you’re on those platforms. Attackers grab temporary IAM credentials, service account tokens, or instance details, escalating to full cloud compromise. Internal services on private networks face the same risk: databases, APIs, whatever lacks proper network segmentation.

Who Gets Hit and Why It Matters

Only multi-tenant HTTP mode suffers. Single-tenant stdio or HTTP without multi-tenant headers dodge it. n8n-mcp handles proxying for n8n’s cloud and self-hosted instances, often running in containers on Kubernetes or Docker in production. If you deploy n8n across multiple clouds or regions with shared auth, you’re exposed. Eresus Security Research found this; they disclosed responsibly, and maintainers patched in 2.47.4 on the same day as public notice.

Implications cut deep. SSRF isn’t new—it’s a top OWASP risk for a reason—but authenticated SSRF turns insiders or compromised tokens into infrastructure killers. Steal creds from IMDSv1 (still common despite v2 pushes), pivot laterally. In multi-tenant, one sloppy operator shares a token with a script kiddie or vendor integration? Game over. n8n users often automate sensitive workflows—finance, CRM, HR—so this proxy’s compromise ripples wide. Expect attackers to chain it with token theft from logs or clients. Fair note: requires auth, so no zero-day worm, but negligence amplifies it.

Scale matters. n8n claims over 50,000 community instances; enterprise users hit thousands of workflows daily. No public exploits yet, but GitHub advisories like this draw eyes. Check your deps: npm shows n8n-mcp at 2.47.3 pulled over 10,000 weekly downloads pre-patch.

Fix It Now: Patches and Workarounds

Upgrade to n8n-mcp 2.47.4 or later. The patch adds URL validation at header entry points and normalizes them in the API client—no config tweaks needed. Run

npm update n8n-mcp

or pull the latest Docker image. Test in staging; multi-tenant flag ENABLE_MULTI_TENANT stays if you need it.

Can’t patch today? Layer defenses:

1. Block outbound from n8n-mcp containers. iptables or cloud firewalls deny RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local 169.254.0.0/16, and custom internals. Example iptables:

   iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
   iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
   iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
   iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

   This kills SSRF broadly—do it anyway, post-patch.

2. Disable multi-tenancy: Unset ENABLE_MULTI_TENANT env var. Strip x-n8n-url and x-n8n-key at your reverse proxy (Nginx, Traefik). Config snippet for Nginx:

   proxy_hide_header x-n8n-url;
   proxy_hide_header x-n8n-key;
   if ($http_x_n8n_url) { return 403; }

3. Lock down AUTH_TOKEN. Distribute only to trusted ops. Rotate if suspect exposure. Use short-lived tokens if possible.

Post-fix, audit logs for funky requests. Scan networks for open IMDS—force v2 everywhere. n8n-mcp’s quick patch shows solid response, but this exposes sloppy multi-tenant reliance. Self-hosters, rethink token hygiene. Cloud teams, egress rules are table stakes. Act fast; one bad fetch hands attackers your keys.