Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
mcp-searxng version 1.11.0 exposes SearXNG Basic Authentication credentials embedded in the SEARXNGURL environment variable. When the server starts in STDIO mode and an MCP client connects, the complete SEARXNGURL, including its username and password, is sent to the client through an MCP notifications/message logging notification. Additionally, when URL validation fails, the complete credential-bearing URL is included in the configuration error. This error is logged through MCP and returned to the client as a JSON-RPC error response. For example, a value such as: is exposed without redaction. A connected MCP client or anyone with access to captured server logs may recover the SearXNG credentials and use them to access the configured SearXNG instance. The issue was confirmed in: Suggested severity: Medium Details mcp-searxng supports SearXNG Basic Authentication by embedding credentials in the URL userinfo component: The project contains a redaction function named…
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
mcp-searxng has a hardened-mode URL-reading feature intended to prevent weburlread from reaching private or internal network resources. PR #79 appears to address one SSRF class: hostnames that resolve to private or internal addresses under hardened mode. I tested PR #79 locally and confirmed that it blocks the DNS-resolves-to-loopback case. However, several other hardened-mode SSRF bypasses still appear to remain: 1. Redirects from an allowed first-hop URL to a loopback/internal URL are followed without re-validating the redirect target. 2. 0.0.0.0 is not treated as an internal/special address. 3. IPv4-mapped IPv6 literals can bypass private-address checks after URL canonicalization. With hardened mode enabled and private URLs not explicitly allowed, weburlread was still able to fetch and return content from a local loopback sentinel service in all three cases. Tested configuration The MCP server was driven over stdio. The test target was a harmless internal sentinel HTTP…
Recommended action: Upgrade to 1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DNS-resolved Private Hostname SSRF in weburlread Summary The weburlread MCP tool in mcp-searxng is vulnerable to Server-Side Request Forgery (SSRF) via DNS rebinding bypass. The assertUrlAllowed() function at src/url-reader.ts:85-93 validates only the syntactic hostname string against a private IP/hostname blocklist without performing DNS resolution. An attacker who controls a domain that resolves to a private or loopback IP address (e.g., via a wildcard DNS service like nip.io, or a custom DNS entry) can bypass the security check and cause the MCP server to read arbitrary internal HTTP services reachable from the server host. This allows exfiltration of sensitive data from internal services with no authentication required in the default HTTP configuration. Details The vulnerable code is in src/url-reader.ts, where the assertUrlAllowed() function performs a hostname-only string comparison: This function checks whether url.hostname lexically matches a private address pattern but never…
Recommended action: Upgrade to 1.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unbounded Response Body Read Bypasses URL Size Limit in weburlread Summary The weburlread MCP tool in mcp-searxng enforces its 5 MiB response-size limit exclusively by inspecting the Content-Length header of a preliminary HEAD request. When a server omits Content-Length — a standard HTTP practice — checkContentLength() returns null, the guard condition short-circuits to false, and response.text() loads the entire response body into memory without any byte cap. An unauthenticated attacker who controls or can redirect to an HTTP endpoint can force the server process to consume unbounded memory and CPU, leading to a Denial of Service. Details weburlread is the entry point (src/index.ts:226-240). It passes the caller-supplied URL directly into readUrlContent() in src/url-reader.ts. Size-limit check (bypassed) checkContentLength() (src/url-reader.ts:243-245) returns null when the HEAD response carries no Content-Length header. Because the guard uses the !== null conjunction, a null result…
Recommended action: Upgrade to 1.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.