iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SSRF in an MCP server happens when the server makes a network request to a destination chosen or influenced by an attacker. In four reported cases, URLs passed through different trust checks—or around them—before the server made the request. A model call is not a reason to trust a URL: content an attacker controls may steer the model to provide it.
Who is the attacker in an MCP server SSRF?
The attacker does not necessarily call the MCP server directly. They may control a webpage, document, or other content that an AI model is asked to read. That content can try to persuade the model to use a fetch or browser tool with an attacker-chosen URL. If the server follows the request, it may reach systems or credentials available from its own runtime network position but not from the attacker’s.
That can include loopback services, private network endpoints, cloud metadata services, or credentials exposed to the server. The outcome is not automatic: it depends on the server’s network access and credentials, the tools and permissions enabled, and whether the model follows the malicious instruction. The security boundary is the destination the server actually contacts—not merely the tool schema or the URL initially configured by an operator.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsHow did the four cases differ?
| Implementation | Reported URL trust failure | Evidence and status checked through October 7, 2026 |
|---|---|---|
| Google MCP Toolbox for Databases | Generic HTTP source; initial destination and redirects | PR #3448 merged June 18, 2026; linked release notes show version 1.5.0 that day. |
Anthropic reference mcp-server-fetch |
Fetch without internal-address filtering; a prompt handler bypassed an autonomy check | NVD record CVE-2026-104120 lists affected mcp-server-fetch and mcp-server-everything versions through 2026.6.4; it says the fix pull request awaits acceptance. |
Microsoft playwright-mcp |
browser_navigate accepted arbitrary URLs, potentially including internal endpoints |
Issue #1626 is closed; the inspected issue page does not establish a merged fix or a release containing one. |
| Weaviate Google modules | Google module apiEndpoint did not receive the earlier hardening applied to fields named baseURL |
PR #12961 merged September 7, 2026, into stable/v1.37; it restricts the Google module’s endpoint, region, and location to Google API hosts. |
Google MCP Toolbox: check the connection destination and redirects
Syed Anas Mohiuddin’s September 2026 account reports CVE-2026-14540 for MCP Toolbox versions 0.3.0 through 1.4.0. The affected range is also reflected in an NVD search record. Mohiuddin attributes a CVSS 4.0 score of 8.0 and a July 31, 2026 publication date to the CVE; those details should be understood as his report, rather than as independently verified NVD page content.
The repository’s PR #3448 documents an SSRF guard that validates IPs for connections and redirects. Its linked release notes show version 1.5.0 dated June 18, 2026. This illustrates why checking only the first URL is insufficient: a permitted initial destination could redirect the server elsewhere unless each redirect target is validated too.
Anthropic’s reference fetch server: cover every handler
Mohiuddin’s May 25, 2026 Full Disclosure advisory describes arbitrary URL fetching without internal-address filtering in the reference fetch server. It also identifies a distinct path through get_prompt, which called fetch_url() without the autonomy check used elsewhere. Mohiuddin described that finding this way: “The get_prompt handler calls fetch_url() directly without invoking check_may_autonomously_fetch_url(), bypassing the robots.txt autonomy guard through a structurally distinct code path (logic bypass).”
The later NVD record, CVE-2026-104120, was dated October 2 and modified October 6, 2026. It lists mcp-server-fetch and mcp-server-everything through version 2026.6.4 and identifies CWE-918. The record says the fix pull request awaits acceptance, so the material available here does not establish a released fixed version. The same record lists a CVSS-BT 5.5 score from VulDB; that is distinct from Mohiuddin’s researcher-assigned CVSS 7.5 in the May disclosure, not a replacement for it.
A separate modelcontextprotocol/servers issue, #4116, opened May 6, 2026, raised defense-in-depth concerns about internal network access, redirects, response size, and DNS rebinding. It is closed as “not planned”; its author described the concerns as defense in depth, not as a known exploit in a particular deployment. Closure of that issue does not establish that a fix shipped.
Microsoft Playwright MCP: browser navigation is network access
Issue #1626, opened May 22, 2026, describes arbitrary URLs supplied to browser_navigate as a possible route to internal endpoints. The advisory published May 25 by Mohiuddin covers this issue alongside the Anthropic fetch-server finding and assigns the disclosure a CVSS 7.5 score. That score is the researcher’s assessment, not a vendor-issued rating in the material examined here.
The issue currently appears closed, but its inspected page does not show a merged code change or identify a release containing a fix. Treating a closed issue as proof of remediation would overstate what the status establishes.
Weaviate Google modules: a different field name left a gap
Mohiuddin reports that earlier hardening applied to fields named baseURL, while Google modules used apiEndpoint. If an attacker could control that endpoint, the issue could expose an operator’s Google API key or GCP OAuth token. PR #12961 merged on September 7, 2026, into stable/v1.37 and restricts the Google module’s apiEndpoint, region, and location to Google API hosts. The account highlights a practical audit risk: security controls can miss equivalent configuration values when they are named or handled differently.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →How to reduce SSRF risk in an MCP deployment
Use a shared destination policy for every part of the server that can make a network request. A tool method may not be the only entry point; prompts, secondary handlers, redirects, and other network-capable code paths need equivalent checks.
- List every network-capable path. Audit tools, prompt handlers, browser navigation, and secondary routes that fetch or follow URLs. Trace each path to the actual network call, rather than stopping at the model-facing tool schema.
- Set an explicit destination policy. Restrict schemes and destinations; use allowlists where the workflow permits. Reject loopback, private, link-local, and other reserved address ranges unless an operational need justifies them.
- Validate the address used for the connection. Resolve names and constrain the actual connection address, not just the hostname string. This helps reduce DNS rebinding and time-of-check/time-of-use gaps between validation and connection.
- Recheck every redirect. Validate each redirect destination before following it. A safe initial URL does not make a later destination safe.
- Limit response size while reading. Enforce byte limits during streaming or reads, rather than buffering an unbounded response and trimming the text afterward.
- Constrain outbound network access. Use network-level egress rules and protect cloud metadata services as defense in depth. These controls can limit impact if an application-level check is missed.
When reviewing an implementation, assess initial URL validation, resolved-IP validation and DNS rebinding resistance, redirect-hop checks, coverage of all handlers, response-size enforcement, and network-level egress and metadata controls. These are useful review dimensions, not a benchmark or ranking of products.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What the reports establish—and what they do not
The four cases show distinct ways a URL can cross a trust boundary: an unchecked redirect or connection address, a fetch path that bypasses a guard, browser navigation to an arbitrary URL, or a differently named endpoint outside earlier hardening. They do not prove that every MCP server is vulnerable.
In his May 2026 advisory, Mohiuddin reported that 27.8% of 54 production MCP servers he scanned had HIGH or CRITICAL findings, that 8 of 54 (14.8%) had confirmed SSRF, and that 7 of 54 had credential exposure. Those are results from his scan; the advisory does not establish a representative sampling frame, so they should not be read as prevalence estimates for MCP servers generally. The cited material does not establish an industry-wide SSRF prevalence statistic.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Mohiuddin’s September account captured the shared issue as: “In every case, a URL crossed a trust boundary and nobody was standing at the boundary.” For operators, the practical lesson is to treat model-influenced input as untrusted and verify the destination at the point the server connects.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
