EUVD-2026-28825
GHSA-cmrh-wvq6-wm9r
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
6DescriptionGitHub Advisory
Summary
Authenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (N8N_API_URL), and per-request URLs supplied via the x-n8n-url header in multi-tenant HTTP mode.
Impact
A caller with access to the MCP session can drive HTTP requests from the n8n-mcp host to internal services and cloud metadata endpoints that the SSRF gate is meant to block. The response body is returned to the caller, making internal-service enumeration and credential theft immediate without any out-of-band channel.
- Multi-tenant HTTP deployments where tenants share an
AUTH_TOKEN: any tenant with valid credentials can reach the operator's cloud metadata service and exfiltrate temporary IAM / GCP service account / Azure managed-identity credentials. - Single-tenant deployments: indirect prompt injection through tool arguments reaches the same surface; an attacker who can influence the LLM's tool calls can read internal services from the n8n-mcp host.
- Stdio deployments are reachable via the same prompt-injection path.
Patched Versions
Fixed in n8n-mcp@2.50.2.
Note for operators: The same SSRF gate that previously covered webhook URLs now also covers the n8n API client base URL. If N8N_API_URL points at http://localhost:5678 (n8n on the same host) or an RFC1918 address (n8n on the same private network), set WEBHOOK_SECURITY_MODE=moderate (allows localhost, still blocks RFC1918 and cloud metadata) or WEBHOOK_SECURITY_MODE=permissive (allows RFC1918 too - only safe on a trusted private network). Default strict is correct for deployments where n8n is reachable at a public hostname.
Workarounds
For deployments that cannot upgrade immediately:
- Restrict network egress from the n8n-mcp host with a firewall, reverse proxy, or cloud security group. Explicitly deny cloud metadata IPs (
169.254.169.254,169.254.170.2,100.100.100.200,192.0.0.192, and the GCPmetadata.google.internalresolved IP) and any RFC1918 networks the server does not legitimately need to reach. - Run in stdio mode instead of HTTP if the multi-tenant surface is not needed (no shared
AUTH_TOKENto compromise). - Disable workflow management tools via
DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflowif the deployment does not need them.
Credit
Reported by @fg0x0.
AnalysisAI
Server-side request forgery in n8n-mcp versions 2.18.7 through 2.50.1 allows authenticated attackers with MCP session access to bypass SSRF protections and send HTTP requests to cloud metadata endpoints and internal services, with response bodies returned directly to the attacker. Multi-tenant HTTP deployments are critically exposed: any tenant sharing an AUTH_TOKEN can exfiltrate AWS IAM, GCP service account, or Azure managed identity credentials from the operator's cloud metadata service (169.254.169.254 and related endpoints). Single-tenant and stdio deployments remain vulnerable via indirect prompt injection attacks that manipulate LLM tool calls. Vendor-released patch: n8n-mcp version 2.50.2. No CVSS score assigned; no public exploit code identified at time of analysis, though the advisory contains sufficient technical detail for proof-of-concept development.
Technical ContextAI
n8n-mcp is an npm package (pkg:npm/n8n-mcp) that provides Model Context Protocol (MCP) integration for n8n workflow automation. The vulnerability stems from insufficient SSRF protection in three attack surfaces: webhook trigger tools, the n8n API client configured via the N8N_API_URL environment variable, and per-request URLs passed through the x-n8n-url HTTP header in multi-tenant mode. The root cause (CWE-367, Time-of-check Time-of-use Race Condition) suggests a timing vulnerability in the SSRF gate validation logic, allowing attackers to bypass blocklists for RFC1918 private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata service endpoints. Cloud metadata services expose temporary credentials and instance metadata at link-local addresses: AWS EC2 (169.254.169.254), AWS ECS (169.254.170.2), Alibaba Cloud (100.100.100.200), Azure (192.0.0.192), and GCP (metadata.google.internal). The MCP session provides an authenticated channel for attackers to craft tool arguments or HTTP headers that trigger server-side requests, with full response bodies returned in-band rather than requiring blind exfiltration techniques. Multi-tenant HTTP mode is particularly vulnerable because multiple tenants authenticate with a shared AUTH_TOKEN, allowing lateral movement between tenant boundaries.
RemediationAI
Upgrade immediately to n8n-mcp version 2.50.2, confirmed fixed per vendor advisory. Critical post-upgrade configuration step: if your N8N_API_URL points to localhost (http://localhost:5678 or http://127.0.0.1:5678) or RFC1918 private addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x), you must set WEBHOOK_SECURITY_MODE environment variable to 'moderate' (allows localhost, blocks RFC1918 and cloud metadata-suitable when n8n runs on same host) or 'permissive' (allows RFC1918-only safe on isolated trusted networks with no cloud metadata access). The default 'strict' mode will break localhost/private network communication but is correct for public hostname deployments. Failure to configure WEBHOOK_SECURITY_MODE will cause service disruption after upgrade. For environments unable to upgrade immediately, implement network-layer egress controls using firewall rules, AWS Security Groups, GCP VPC firewall, or Azure NSGs to explicitly deny outbound traffic to 169.254.169.254/32, 169.254.170.2/32, 100.100.100.200/32, 192.0.0.192/32, and resolve metadata.google.internal to block its current IP. Also block RFC1918 ranges unless explicitly required for n8n API communication. As secondary mitigation, switch from multi-tenant HTTP mode to stdio mode if tenant isolation is not operationally required, eliminating the shared AUTH_TOKEN attack surface. Disable workflow management tools by setting DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflow if these features are unused, though this only reduces attack surface and does not eliminate the SSRF via N8N_API_URL or x-n8n-url header. Network egress restrictions have the trade-off of blocking legitimate internal API calls-audit your n8n workflows for dependencies on internal services before implementing. Advisory and patch details at https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-cmrh-wvq6-wm9r.
Share
External POC / Exploit Code
Leaving vuln.today