CVE-2026-54688: SSRF
Ref: https://github.com/ihor-sokoliuk/mcp-searxng/issues/87#issuecomment-4645453694
Summary The weburlread tool fetches a caller-supplied URL server-side and converts it to markdown. An SSRF guard (assertUrlAllowed, which blocks private/loopback/metadata addresses) exists but runs only when MCPHTTPHARDEN=true, which is off by default. So in the default configuration there is no internal-address filtering, and an attacker who can influence the URL can make the server fetch internal services and cloud metadata and return their content. Confirmed on 1.1.0 (default config): weburlread fetched a local internal sentinel and returned its content.
Details dist/index.js (around lines 90-101): weburlread calls fetchAndConvertToMarkdown on the caller URL. dist/url-reader.js (around lines 44-52): assertUrlAllowed performs the private-IP/loopback check, but only when the hardening flag is set; dist/http-security.js (around line 11) defaults MCPHTTPHARDEN to off. With the default config the check is skipped entirely. Even when enabled, the check is literal-hostname based with no DNS-rebinding or redirect re-check (the fetch follows redirects). file:// is rejected, so this is HTTP/HTTPS SSRF.
PoC Re-validated on mcp-searxng 1.1.0 over MCP stdio in the default configuration (MCPHTTPHARDEN not set): tools: searxngwebsearch, weburlread weburlread({ url: "http://127.0.0.1:<port>/internal" }) -> server fetched the internal sentinel; SSRF: CONFIRMED The server fetched the loopback sentinel and returned its content. With MCPHTTPHARDEN=true the same request is blocked (policy error), confirming the guard exists but ships off. The same reaches http://169.254.169.254/... on cloud hosts.
Impact In the default configuration an attacker who can influence the URL (LLM-produced and steerable via prompt injection) can make the server fetch internal-only HTTP services and the cloud metadata endpoint, returning their contents into the model context for exfiltration. The protection that would prevent it is not enabled by default.
Remediation Enable the internal-address filtering by default (fail safe): make assertUrlAllowed run unconditionally and require an explicit opt-out only for trusted environments. Strengthen the check to resolve the host and reject loopback, link-local/metadata (169.254.0.0/16), 0.0.0.0/8, and private ranges, and re-validate on every redirect hop (or pin to the validated IP).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/mcp-searxngto a version that resolves this vulnerability.Fixed in 1.2.1 - Configuration
Set MCP_HTTP_HARDEN to true by default so assertUrlAllowed runs unconditionally (fail-safe) and blocks private/loopback/link-local/metadata destinations during web_url_read SSRF checks.
mcp-http hardening (assertUrlAllowed / dist/http-security.js) MCP_HTTP_HARDEN = true - Configuration
Strengthen assertUrlAllowed to resolve the hostname to an IP and reject loopback, link-local/metadata (169.254.0.0/16), 0.0.0.0/8, and private ranges; additionally re-validate the destination on every redirect hop (or pin the validated IP) so redirects can’t bypass the check.
assertUrlAllowed (dist/url-reader.js) SSRF allow/deny policy = enhanced (resolve host + validate every redirect hop) - Compensating control
If changing code/config isn’t immediately possible, restrict the network egress of the MCP server so it cannot reach private address ranges and the cloud metadata endpoint (e.g., block access to loopback/private and 169.254.169.254 from the host/container running web_url_read).
Event History
Frequently Asked Questions
Is the default deployment exposed?
Yes. MCP_HTTP_HARDEN is off by default, so web_url_read does not apply the private-address, loopback, or metadata-address filtering in the default configuration.
What access does an attacker need?
An attacker needs to be able to influence the URL passed to web_url_read. No authentication or special server-side privileges are described as necessary, but exploitation requires the tool to process the attacker-controlled URL.
What systems or data could be reached?
The vulnerable server can be induced to fetch internal services, local or loopback endpoints, and cloud metadata services, then return fetched content as markdown. The reported impact is exposure of content available to the server rather than modification or denial of service.
What can be done if an update cannot be applied immediately?
Set MCP_HTTP_HARDEN=true to enable the available URL check. This is only a partial mitigation: the check is based on the literal hostname and does not re-check DNS rebinding or redirects, while fetches follow redirects.
How can I assess whether an instance is affected?
Check whether web_url_read is enabled and whether MCP_HTTP_HARDEN is unset or false. The issue was confirmed against version 1.1.0 using the default configuration, where a local internal sentinel could be fetched and its content returned.