EresusSecurity
Back to Research
Security Advisories

n8n-mcp Authenticated SSRF: Disclosure and Mitigation (CVE-2026-39974)

Yiğit İbrahim SağlamOffensive Security Specialist
April 9, 2026
Updated: October 18, 2026
3 min read

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.

Severity and impact context

GitHub Advisory Database lists CVE-2026-39974 as High, CVSS v3.1 8.5. The issue affects n8n-mcp versions through 2.47.3; 2.47.4 is the patched version. Severity is not a statement that every deployment has the same exposure: the advisory identifies multi-tenant HTTP deployments with valid AUTH_TOKEN access as the primary risk, while single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected.

The SSRF can make the server request arbitrary URLs and return response bodies to the caller. Whether that exposes cloud metadata or internal data depends on the server's reachable network and the credentials available to the caller; the advisory does not establish that every affected deployment has exposed credentials.

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.

AI Security Starter Training

Request a practical checklist for prompt injection, RAG data leakage, MCP risks, and model-file security before launch.

Prompt injection and guardrail bypass checks.
RAG data leakage and permission-boundary review.
MCP identity, transport, and command-risk controls.

No spam. Used only to send the resource and related security notes.

Related Services

MCP Security →AI Agent Security →LLM Red Teaming →

Scope Estimator

Get a rough engagement size before the scoping call.

Estimated engagement

5–7 days

Request exact scope