CVE-2026-58485
HighCVSS 7.1Summary
In mcp-searxng before 1.7.1, web_url_read accepts a caller-controlled URL and validates only the literal hostname in assertUrlAllowed() before undiciFetch() performs OS DNS resolution. A public-looking attacker-controlled hostname that resolves to a private, loopback, link-local, or cloud-metadata address passes the lexical check and causes the MCP server to connect to the internal destination. In the default HTTP configuration, an unauthenticated network client can read internal services, expose credentials or tokens, and enumerate reachable internal hosts. Fixed in version 1.7.1.
Risk Assessment
An unauthenticated attacker can exploit the SSRF vulnerability to access internal services, expose credentials or tokens, and map internal infrastructure. In environments with cloud metadata access, this may lead to identity theft or privilege escalation.
Recommendation
Upgrade mcp-searxng to version 1.7.1, which properly validates the scheme, host, and resolved IP address. Until patched, consider disabling or restricting access to the web_url_read tool and ensure MCP_HTTP_ALLOW_PRIVATE_URLS is not enabled.
Other vulnerabilities in mcp-searxng
See all- CVE-2026-58483High
In mcp-searxng before 1.7.1, web_url_read passes a caller-supplied URL to readUrlContent(), where checkContentLength() treats a missing Content-Length header as an inconclusive preflight and the normal and error paths then consume the complete body with response.text(). A server that omits Content-Length can bypass URL_READ_MAX_CONTENT_LENGTH_BYTES and force unbounded memory use, and the resulting string is processed by NodeHtmlMarkdown.translate(), increasing CPU consumption. An unauthenticated HTTP client can cause denial of service. Fixed in version 1.7.1.
- CVE-2026-54689Medium
mcp-searxng before version 1.2.0 has a vulnerability in the web_url_read URL policy that can be bypassed when MCP_HTTP_HARDEN is enabled and MCP_HTTP_ALLOW_PRIVATE_URLS is not enabled. The bypass is due to lack of revalidation of redirect targets, 0.0.0.0 not being classified as internal, and IPv4-mapped IPv6 literals in hexadecimal form not being recognized. An attacker can influence a tool call to make the MCP server fetch loopback or internal HTTP resources and return their content.
- CVE-2026-54688Medium
mcp-searxng before version 1.2.0 has a vulnerability where web_url_read passes a caller-supplied URL to the server-side fetch path, and assertUrlAllowed() runs only when MCP_HTTP_HARDEN is enabled, which is disabled by default. In the default configuration, an attacker who influences the URL selected by a user or AI agent can make the server fetch loopback, private-network, or cloud metadata endpoint resources and return their contents into the model context.
Original NVD description (English source)
mcp-searxng is a Model Context Protocol server that gives AI assistants web search and URL-reading capabilities through SearXNG. Prior to 1.7.1, web_url_read receives its caller-controlled URL through src/index.ts and validates only the literal hostname in assertUrlAllowed() within src/url-reader.ts before undiciFetch() performs operating-system DNS resolution. A public-looking attacker-controlled hostname that resolves to a private, loopback, link-local, or cloud-metadata address therefore passes the lexical check and causes the MCP server to connect to the internal destination. In the default HTTP configuration, an unauthenticated network client can use this path to read internal services, expose credentials or service tokens, and enumerate reachable internal hosts; in STDIO deployments, prompt-influenced tool selection can provide the malicious URL. Direct private IP literals are blocked, and MCP_HTTP_ALLOW_PRIVATE_URLS remains an explicit opt-out. This issue is fixed in version 1.7.1.