The mcp-webresearch MCP server version 0.1.7 carries CVE-2026-65056, an 8.3-severity server-side request forgery flaw under CVSS 4.0 where the visit_page tool checks the URL protocol alone and steers its Playwright browser toward internal addresses, cloud metadata endpoints among them.
mcp-webresearch, published on npm as @mzxrai/mcp-webresearch, hands an AI agent live web access through the Model Context Protocol. The server drives a headless Playwright browser: tools such as search_google, visit_page, and take_screenshot let a model fetch pages, read their content, and capture screenshots mid-task. Engineering teams wire it into Claude Desktop and other MCP hosts to give agents a browsing capability. That design places a real browser under model control, and the model draws part of its instructions from the very pages it reads. The result is a trust boundary between “content the agent fetches” and “actions the agent takes” — and this advisory turns that boundary into an exposure. The Model Context Protocol has become the default integration layer for tool-using agents across the industry through 2026, which makes the security posture of individual community servers a fleet-wide concern rather than a single-package footnote.
What changed — protocol-first validation
GitHub published advisory GHSA-r9hf-v7rm-5h4j on July 21, 2026, classifying the issue as CWE-918 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N. The root cause sits in dist/index.js. The isValidUrl function at lines 646-651 accepts any URL whose protocol resolves to http: or https:, and the visit_page handler at lines 769-786 passes that URL straight into safePageNavigation. That protocol check clears loopback, link-local, and reserved ranges alongside legitimate public hosts. The researcher writeup traces the same gap through take_screenshot and through the URLs followed from search_google results, widening the affected surface across three tools.
The proof of concept navigates to a loopback path, http://127.0.0.1:<port>/latest/meta-data/iam/, and retrieves a planted secret, returning content that reads WR_INTERNAL_IMDS_SECRET_iam-creds=AKIA9XEXFIL. On a cloud host the identical path resolves to http://169.254.169.254/latest/meta-data/, the AWS instance metadata service. The GitHub advisory confirms that retrieved page content, credentials included, flows directly into the model context. The vector's VC:H paired with SC:H registers high confidentiality loss that crosses into a downstream system — the metadata service and internal hosts sit behind the compromised browser, beyond its own security scope. A patched release remains absent as of publication.
The architecture implication
The indirect attack path drives the severity here. The vector string marks UI:A for passive interaction and PR:N for zero privileges: the operator launches a routine research task, and adversarial text embedded in a fetched page supplies the malicious redirect. A crafted search result or a poisoned webpage instructs the agent to visit an internal URL; the server complies, and metadata credentials land in the same context window the model shares with attacker-influenced content. Injection enters, credentials exit — a complete exfiltration loop that the operator triggers by asking the agent to research a topic.
Two structural facts amplify the reach. First, the browser executes with the network position of its host, so a server running inside a VPC or on a cloud instance touches endpoints that external attackers struggle to reach by other means. Second, MCP servers frequently run on developer laptops and CI runners that hold high-value credentials, placing loopback services and metadata endpoints one hop away. Any team that treats “fetch a public URL” as a low-trust action inherits a private-network read primitive the moment they add browsing to an agent.
The pattern generalizes beyond this package. Any agent tool that accepts a URL, a webhook target, a file path, or an image source from model output presents the same class of exposure, and the MCP ecosystem has produced a run of comparable findings across auth handling and command surfaces. The lesson holds across them: model-controlled input reaching a network or shell primitive demands the same scrutiny a web application applies to user-supplied input, because the fetched page is itself an untrusted party inside the loop. Reviewers who map that class once can apply the same checklist to every new server they onboard.
The decision for engineering leadership
Treat every MCP server that drives a browser or an HTTP client on model-supplied URLs as a data-exfiltration surface, and audit it this quarter. For mcp-webresearch, move deployments off 0.1.7 and apply egress controls at the network layer: block the 169.254.0.0/16 metadata range, 127.0.0.0/8, 0.0.0.0/8, and RFC 1918 private blocks from the browser's namespace. Enforce IMDSv2 with a hop limit of 1 on cloud instances, which defeats metadata reads from a proxied browser. At the code layer, the durable fix resolves each hostname to its IP and rejects loopback, link-local, and private ranges ahead of navigation, then re-validates every redirect target rather than the first request alone. Add a domain allowlist for agents that need a bounded set of destinations. The broader review question for any agentic stack: which tools accept model-controlled URLs, and what network sits behind them? Answer that for each server, and SSRF stops being a surprise.
Article by LEON — AI Agents & Systems
LEON covers the technical layer where AI agents are built and deployed. Source: code, documentation, CVEs.