{"id":"CVE-2026-39974","aliases":["EUVD-2026-20968","GHSA-4ggg-h7ph-26qr"],"status":"published","title":"n8n-MCP has an Authenticated SSRF via instance-URL header in multi-tenant HTTP mode","description":"n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, 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. This vulnerability is fixed in 2.47.4.","severity":{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00322,"percentile":0.25508,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-918"],"published":"2026-04-08T19:53:48Z","modified":"2026-10-28T02:30:57Z","fixes":[{"ecosystem":"npm","package":"n8n-mcp","fixed_in":["2.47.4"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"n8n-mcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"2.47.3"},{"fixed":"2.47.4"}]}]},{"source":"osv","ecosystem":"npm","package":"n8n-mcp","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.47.4"}]}]}],"products":[{"vendor":"czlonkowski","product":"n8n-mcp"},{"vendor":"n8n-mcp","product":"n8n-mcp"}],"references":[{"url":"https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-4ggg-h7ph-26qr","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://github.com/czlonkowski/n8n-mcp/commit/d9d847f230923d96e0857ccecf3a4dedcc9b0096","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.47.4","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-39974","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-4ggg-h7ph-26qr"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39974.json","tags":["advisory"]},{"url":"https://github.com/czlonkowski/n8n-mcp","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-39974","title":"n8n-MCP has an Authenticated SSRF via instance-URL header in multi-tenant HTTP mode","description":"n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, 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. This vulnerability is fixed in 2.47.4.","status":"published","published":"2026-04-09T16:45:20.49Z","modified":"2026-04-13T20:09:26.781Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:20:02.290587Z"}],"euvd":[{"id":"EUVD-2026-20968","description":"n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, 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. This vulnerability is fixed in 2.47.4.","status":"published","published":"2026-04-09T16:45:20Z","modified":"2026-04-13T20:09:26Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high"}],"updated_at":"2026-11-02T19:24:27.052992Z"}],"ghsa":[{"id":"GHSA-4ggg-h7ph-26qr","title":"n8n-mcp has authenticated SSRF via instance-URL header in multi-tenant HTTP mode","description":"## Impact\nAn 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.\n\nThe 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.\n\n## Affected versions\n`n8n-mcp` ≤ `2.47.3` (all versions up to and including 2.47.3).\n\n## Patched versions\n`n8n-mcp` `2.47.4` and later.\n\n## Workarounds\nIf you cannot immediately upgrade:\n1. **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.\n2. **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.\n3. **Restrict `AUTH_TOKEN` distribution** — ensure the bearer token is only held by fully trusted operators until you can upgrade.\n\n## Remediation\nUpgrade 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.\n\n## Credits\nReported by the Eresus Security Research Team. @ibrahmsql","status":"published","published":"2026-04-08T19:53:48Z","modified":"2026-04-09T19:05:58Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:39:52.102227Z"}],"nvd":[{"id":"CVE-2026-39974","description":"n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, 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. This vulnerability is fixed in 2.47.4.","status":"published","published":"2026-04-09T17:16:30.933Z","modified":"2026-10-26T21:10:00.17Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T14:12:13.902911Z"}],"osv":[{"id":"CVE-2026-39974","title":"n8n-MCP has an Authenticated SSRF via instance-URL header in multi-tenant HTTP mode","description":"n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, 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. This vulnerability is fixed in 2.47.4.","status":"published","published":"2026-04-09T16:45:20.49Z","modified":"2026-10-28T02:30:57.624790316Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:45:03.040464Z"},{"id":"GHSA-4ggg-h7ph-26qr","title":"n8n-mcp has authenticated SSRF via instance-URL header in multi-tenant HTTP mode","description":"## Impact\nAn 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.\n\nThe 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.\n\n## Affected versions\n`n8n-mcp` ≤ `2.47.3` (all versions up to and including 2.47.3).\n\n## Patched versions\n`n8n-mcp` `2.47.4` and later.\n\n## Workarounds\nIf you cannot immediately upgrade:\n1. **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.\n2. **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.\n3. **Restrict `AUTH_TOKEN` distribution** — ensure the bearer token is only held by fully trusted operators until you can upgrade.\n\n## Remediation\nUpgrade 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.\n\n## Credits\nReported by the Eresus Security Research Team. @ibrahmsql","status":"published","published":"2026-04-08T19:53:48Z","modified":"2026-04-09T19:16:17.275218Z","cvss":[{"version":"3.1","score":8.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N","level":"high"}],"cwes":["CWE-918"],"updated_at":"2026-11-02T15:46:37.148947Z"}]}}