Skip to main content
VulnerabilityPublished Updated

CVE-2026-39974: czlonkowski n8n-mcp · Server-Side Request Forgery (SSRF)

Affects czlonkowski n8n-mcpSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 8.5 High : upgrade to 2.47.4 soon.

Data as of 30 Oct 2026, 11:52 UTC

CVSS 3.1 base score
8.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 24% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 2.47.4
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 9 Apr 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 30 Oct 2026.

What to do

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

Affected software

ProductAffectedFixed in
czlonkowskin8n-mcpAffected
  • <2.47.4
Fixed in
  • 2.47.4
GitHubczlonkowski/n8n-mcppkg:github/czlonkowski/n8n-mcpOther threatsAffected
  • <2.47.4
Fixed in
  • 2.47.4

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

AI-suggested

A fixed version (2.47.4) is available that addresses this SSRF vulnerability. For cloud-hosted instances of n8n-mcp, the vendor manages remediation and patch deployment. Users should verify that their environment is updated to version 2.47.4 or later. If operating multi-tenant HTTP deployments, ensure that only trusted clients hold AUTH_TOKENs and consider limiting token sharing. Single-tenant and non-multi-tenant HTTP deployments are not affected and require no action specific to this vulnerability. Patch status is confirmed by the vendor advisory stating the fix is in 2.47.4.

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

References

Community reviews

Loading reviews…