CVE-2026-44694 — n8n-mcp
Fix: czlonkowski/n8n-mcp@bcaba83CVE-2026-44694 is a CWE-367 vulnerability in n8n-mcp. A fix is available for n8n-mcp — see the affected versions and patch details below.
n8n-MCP: Authenticated SSRF in n8n-mcp webhook and API client paths
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-44694.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
n8n-mcpnpmDescription
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:
- 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | n8n-mcp | ≥ 2.18.7&&< 2.50.2 | 2.50.2npm install n8n-mcp@2.50.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for n8n-mcp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update n8n-mcp to 2.50.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44694 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-44694 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-44694. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-44694 in your dependencies?
O3 Security finds CVE-2026-44694 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.