GHSA-xcqx-9jf5-w339

## Unbounded Response Body Read Bypasses URL Size Limit in `web_url_read` ### Summary The `web_url_read` 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 `web_url_read` 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)** ```ts // src/url-reader.ts:352-360 const contentLength = await checkContentLength(...); if (contentLength !== null && contentLength > maxContentLengthBytes) { return createContentTooLargeMessage(contentLength, maxContentLengthBytes); } ``` `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 causes the entire check to evaluate as `false`, and execution falls through without enforcing the configured 5 MiB ceiling. **Unbounded sinks** A full GET request is then issued (`src/url-reader.ts:367`) with no streaming byte cap: ```ts // src/url-reader.ts:414 — normal response path htmlContent = await response.text(); // src/url-reader.ts:402 — error response path (same issue) responseBody = await response.text(); ``` The full HTML string is subsequently passed to `NodeHtmlMarkdown.translate()` (`src/url-reader.ts:429`), which amplifies CPU consumption proportional to the body size. **Default exposure** `web_url_read` is enabled by default. In HTTP transport mode, authentica