GHSA-4ggg-h7ph-26qr: n8n-mcp: authenticated SSRF leaks cloud metadata

Published April 8, 2026

CISO Take

n8n-mcp, the MCP bridge that exposes n8n workflow automation to AI agents, contains an authenticated SSRF flaw allowing any holder of a valid AUTH_TOKEN to force the server to fetch arbitrary URLs and return their full response bodies via JSON-RPC — including cloud instance metadata endpoints (AWS IMDS at 169.254.169.254, GCP, Azure, Alibaba) where a single request can yield IAM temporary credentials enabling full cloud account takeover. Exploitation requires only Low complexity and Low privileges (CVSS 8.5, Scope:Changed), and the package's history of 57 prior CVEs paired with an OpenSSF Scorecard of 5.9/10 signals a structurally risky dependency warranting supply chain scrutiny beyond this single advisory. Upgrade to n8n-mcp 2.47.4 immediately; if patching is blocked, add egress filtering at the network layer to block RFC1918 ranges and 169.254.0.0/16, and disable the ENABLE_MULTI_TENANT flag plus x-n8n-url/x-n8n-key headers at your reverse proxy.

Sources: GitHub Advisory ATLAS OpenSSF

Risk Assessment

High risk in any multi-tenant or shared-token HTTP deployment. CVSS 8.5 with Network vector, Low complexity, Low privileges, and Changed scope indicates cross-boundary impact — specifically, container-to-cloud infrastructure pivoting via credential theft from metadata services. Cloud metadata SSRF is a well-documented, high-yield attack path with real-world precedents of complete cloud account compromise. The 57 existing CVEs in this package and a package risk score of 69/100 compound the baseline risk, making this a dependency that warrants both immediate patching and a longer-term evaluation as an AI supply chain risk. Single-tenant stdio deployments and HTTP installations that have not enabled multi-tenant headers are not affected.

Affected Systems

Package	Ecosystem	Vulnerable Range	Patched
n8n-mcp	npm	<= 2.47.3	`2.47.4`
182.5K OpenSSF 5.9 Pushed 4d ago 14% patched ~2d to patch Full package profile →

Do you use n8n-mcp? You're affected.

Severity & Risk

CVSS 3.1

8.5 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

Recommended Action

Patch: Upgrade n8n-mcp to 2.47.4 or later — no configuration changes required, fix adds URL validation at entry points.
Egress filtering (apply even post-patch as defense-in-depth): 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) and link-local 169.254.0.0/16.
Header controls: If per-request instance switching is not required, unset ENABLE_MULTI_TENANT and block x-n8n-url and x-n8n-key headers at the reverse proxy before they reach the application.
Token hygiene: Rotate AUTH_TOKENs and restrict distribution to fully trusted operators only — treat any shared token as compromised.
Detection: Alert on outbound HTTP requests from the n8n-mcp container to 169.254.169.254, 169.254.170.2, metadata.google.internal, or any RFC1918 destination outside your approved allowlist.

Classification

Data Extraction Auth Bypass Privacy Violation Agent Framework Plugin AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0085.001 - AI Agent Tools AML.T0086 - Exfiltration via AI Agent Tool Invocation

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.2.5 - AI system design and development — security controls

NIST AI RMF

MANAGE-2.2 - Mechanisms to sustain the value of AI systems are developed and applied

OWASP LLM Top 10

LLM07 - Insecure Plugin Design LLM08 - Excessive Agency

Technical Details

NVD Description

## 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: 1. **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. 2. **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. 3. **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

Exploitation Scenario

An attacker holding a valid AUTH_TOKEN — obtained via credential theft, a compromised AI agent, or as a less-trusted tenant in a multi-operator deployment — crafts a JSON-RPC request with an x-n8n-url header set to http://169.254.169.254/latest/meta-data/iam/security-credentials/. The n8n-mcp server, without validating the destination URL, issues the HTTP request and reflects the full response body back in the JSON-RPC reply. The attacker extracts AWS IAM temporary credentials (AccessKeyId, SecretAccessKey, SessionToken) and immediately authenticates against AWS APIs, escalating to full cloud account control. The identical technique applies against GCP metadata.google.internal, Azure IMDS (169.254.169.254), and any internal HTTP service reachable from the container's network namespace, including internal dashboards, configuration services, or adjacent databases.