Skip to main content
VulnerabilityPublished Updated

CVE-2026-44694: czlonkowski n8n-mcp · Time-of-check Time-of-use (TOCTOU) Race Condition

Affects czlonkowski n8n-mcpSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 7.2 High : upgrade to 2.50.2 soon.

Data as of 29 Oct 2026, 19:04 UTC

CVSS 4.0 base score
7.2High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 14% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 2.50.2
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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 8 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade n8n-mcp and czlonkowski/n8n-mcp to 2.50.2.

Affected software

ProductAffectedFixed in
czlonkowskin8n-mcpAffected
  • >=2.18.7 <2.50.2
Fixed in
  • 2.50.2
GitHubczlonkowski/n8n-mcppkg:github/czlonkowski/n8n-mcpOther threatsAffected
  • >=2.18.7 <2.50.2
Fixed in
  • 2.50.2

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

A patch addressing this vulnerability is available in n8n-mcp version 2.50.2. Users should upgrade to version 2.50.2 or later to remediate this issue. Since this is not a cloud service, remediation requires applying the vendor's update. No additional vendor advisory content is provided, so check the vendor's official channels for the latest guidance.

Description

### 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: 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](https://github.com/fg0x0).

References

Community reviews

Loading reviews…