CVE-2026-54688: mcp-searxng: SSRF guard exists but ships off by default

Ref: https://github.com/ihor-sokoliuk/mcp-searxng/issues/87#issuecomment-4645453694 ### Summary The web_url_read 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 MCP_HTTP_HARDEN=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): web_url_read fetched a local internal sentinel and returned its content. ### Details dist/index.js (around lines 90-101): web_url_read 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 MCP_HTTP_HARDEN 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 (MCP_HTTP_HARDEN not set): ``` tools: searxng_web_search, web_url_read web_url_read({ 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 MCP_HTTP_HARDEN=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).

An attacker plants content designed for indirect prompt injection — for example a search-result snippet or a webpage the agent is likely to retrieve via searxng_web_search — containing instructions that steer the LLM into calling web_url_read against http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> or an internal-only admin endpoint like http://127.0.0.1:8080/admin. Because MCP_HTTP_HARDEN is off by default, the server fetches the URL with no SSRF filtering, converts the response to markdown, and returns it directly into the model's context window. The attacker then uses a second injected instruction (or simply observes the conversation if they have access) to get the model to echo or forward that content, exfiltrating cloud credentials or internal service data without ever needing direct network access to the victim's infrastructure.