NewApp Monitoring is liveSign up free
AgentbeamBeta
AI agent vulnerability · Other MCP servers and tools

CVE-2026-44694: n8n-mcp webhook and API client paths has an authenticated SSRF

highCVSS 4.0 7.2GHSA-cmrh-wvq6-wm9r

Summary Authenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (N8NAPIURL), 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.

Published May 8, 2026 · Updated May 13, 2026

Affected packages

n8n-mcp

Ecosystem
npm
Affected
>= 2.18.7, < 2.50.2
Fixed in
2.50.2
Check
npm ls n8n-mcp

Advisory details

From the GitHub Advisory Database (CC BY 4.0).

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 [email protected].

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:

  1. 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 GCP metadata.google.internal resolved IP) and any RFC1918 networks the server does not legitimately need to reach.
  2. Run in stdio mode instead of HTTP if the multi-tenant surface is not needed (no shared AUTH_TOKEN to compromise).
  3. Disable workflow management tools via DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflow if the deployment does not need them.

Credit

Reported by @fg0x0.

Credited to fg0x0.

References

How this page is made: the data panel comes from the GitHub Advisory Database, CISA’s KEV catalog, the NVD and FIRST EPSS, and updates twice a day. No analysis has been written for this entry yet. Methodology

More Other MCP servers and tools vulnerabilities

All Other MCP servers and tools entries