SSRF in MCP servers: the flaw Google and JPMorgan shared

TL;DR. Between May and October 2026, one researcher reported the same server-side request forgery pattern in MCP servers run by Google, JPMorgan Chase, Weaviate, Anthropic, Microsoft, France's DINUM and an Indonesian city government. The instructive case is CVE-2026-14540 in Google's MCP Toolbox for Databases: a database gateway whose SQL tools were guarded while its generic HTTP path followed redirects unchecked. The lesson for anyone operating a database MCP server is that the trust boundary covers every parameter that becomes a network request, and the check belongs where the connection is made, after the address resolves.

SSRF in MCP servers stopped being a hypothetical this year. Independent researcher Syed Anas Mohiuddin spent the spring and summer reporting one bug class, server-side request forgery, across MCP servers from organizations that do not normally share vulnerability writeups: Google, JPMorgan Chase, Weaviate, France's interministerial digital directorate (DINUM) and the city government of Tangerang in Indonesia all shipped fixes, per The Next Web's October 6 report. The highest-profile entry is CVE-2026-14540 in Google's MCP Toolbox for Databases, scored 8.0 High by Google's own CNA. The pattern in every case is the one web security spent fifteen years beating out of application code: a server builds an outbound request from caller-supplied input without checking where the address actually resolves.

What makes this worth a close read on a database blog is which component fell. MCP Toolbox for Databases is a database gateway. Its job is brokering agent access to SQL sources, and that path held. The hole was beside it.

A database gateway fell through its HTTP path

MCP Toolbox for Databases ships source types for the databases it fronts, and alongside them a generic HTTP source for calling REST endpoints. Per the CVE record, the HTTP client in internal/sources/http/http.go was created without a restrictive redirect policy and without target IP validation. A crafted path parameter could send the toolbox through an open redirect or a destination swap, and the follow-up request went wherever the redirect pointed, including internal endpoints the agent could never reach itself.

The mechanics matter because each half defeats a different intuition. The operator configures the HTTP source with a base URL, which feels like the trust decision. It is only the first hop. If the allowed host answers with a 302 pointing at 169.254.169.254, a client with no redirect policy follows it, and the request that lands on the metadata endpoint is the server's own, made from inside the network with the server's standing. Mohiuddin's disclosure writeup puts the general rule plainly: "The model is not a trusted caller."

<img src="/blog/ssrf-mcp-servers-redirect-hop-v1.svg" alt="Two-panel diagram of the same request through an MCP server. In MCP Toolbox 0.3.0 to 1.4.0, hop one reaches an allowed host, a 302 redirect follows, and hop two lands unchecked inside the internal network on the cloud metadata endpoint. In 1.5.0, hop two is resolved and its IP checked at the network boundary, where it is blocked." width="760" height="364" />

The affected range is 0.3.0 through 1.4.0. The fix, pull request #3448 in the googleapis/mcp-toolbox repository, was merged on June 18, 2026 and shipped in v1.5.0 the same day, adding a guard against DNS rebinding plus allowed and blocked IP range lists. Google published the CVE on July 31 and credited Mohiuddin. One calibration note: Google's CVSS v4.0 score is 8.0 High, while NVD's independent v3.1 score is 6.1 Medium, so reasonable scorers read the blast radius differently. What nobody disputes is the mechanism.

The same missing check, across seven codebases

Mohiuddin's own writeup covers four vendors, and the details are worth more than the count, because each one defeats a hardening step the vendor had actually taken:

• Anthropic's mcp-server-fetch and Microsoft's playwright-mcp (disclosed on Full Disclosure, May 25, scored 7.5): neither blocked internal, loopback, link-local or private ranges. The fetch server had a guard function, check_may_autonomously_fetch_url(), but the get_prompt handler never called it, reaching fetch_url() directly. The control existed; a secondary path walked around it.
• Weaviate's Google integration modules: earlier hardening validated the baseURL field. The modules also accept an apiEndpoint field, which stayed unvalidated, and redirecting it to an attacker's host could leak the operator's Google API key or GCP OAuth token. One of the two settings routes was a query-time parameter, reachable with ordinary read access. The fix landed September 7 in stable/v1.37.
• Google's toolbox, covered above: a redirect inherited the trust of the first hop.

The Next Web's reporting adds three organizations beyond that writeup. JPMorgan's open-source documentation-search MCP server had two content-fetching tools: one checked a domain allowlist, and its sibling fetched any caller-supplied URL, in a component forked from an AWS project that never fetched caller-supplied URLs at all. DINUM's MCP server for France's open-data platform fetched URLs supplied by data producers, which could point at internal or cloud metadata addresses. And Tangerang's Wazuh MCP server advertised SSRF protection that rejected literal IP addresses but never resolved hostnames, so any domain pointing at an internal IP sailed through, a high-severity advisory published September 3.

Seven codebases, and not one of them missing the concept of a trust boundary. Each had drawn the boundary around the wrong thing: a field name, a first hop, a literal IP, a primary tool path.

Why a solved web bug reappeared behind the model

SSRF has a CWE number, a spot in the OWASP canon and well-understood countermeasures. It reappeared here because MCP servers invert the old assumption about who supplies the URL. In a web app, a URL parameter arrives from an untrusted user, and everyone knows it. In an MCP server, the request arrives from your own agent, authenticated, running your task, and it feels internal. But the model composes its tool calls from whatever entered its context: a web page it read, a tool result, a poisoned discovery response. The agent is a proxy for every untrusted input upstream of it, which is exactly what Mohiuddin's trusted-caller line compresses.

He gives the broader class a name, protocol pivoting: enter through the model-facing protocol, pivot into whatever the server can reach behind it. In the multi-agent form described in TNW's report, planted text in tool output, shaped like a task for the A2A protocol, gets forwarded by an orchestrating agent to a subagent that executes it on inherited trust. X41 D-Sec's Markus Vervier files that under indirect prompt injection, and the filing fits: the entry point is content, the payoff is reach.

For database MCP servers specifically, this lands on the boundary question we keep returning to. Microsoft's Postgres MCP server states plainly that role permissions are the boundary, and on the SQL path that is an honest answer: the grant decides. An HTTP source, a webhook tool, a documentation fetcher bolted onto the same server sits entirely outside that answer. No Postgres role constrains where a Go HTTP client follows a redirect. Every outbound-capable tool bundled into a database gateway adds a path the database's own permission model never sees, the same residue brokered credentials leave: the guarded path is fine, and the exposure is whatever shipped alongside it.

The audit, if you run a database MCP server

The seven cases translate directly into a checklist, and none of it requires new tooling:

1. Enumerate every tool and source that can make an outbound request. Include prompt handlers and resource fetchers, not only tools. The fetch-server bypass lived in get_prompt.
2. Resolve before you connect, and check the resolved IP. A hostname check that never resolves is the Tangerang bug. DNS rebinding means the check and the connection must see the same answer.
3. Apply the policy to every hop. A redirect is a new destination. A Go http.Client with a nil CheckRedirect follows up to 10 consecutive redirects by default; that default is the Google bug.
4. Block loopback, link-local, private and metadata ranges by default, and treat an allowlist of hosts as a starting point rather than the whole decision.
5. Grep for URL-shaped fields under every name. baseURL being validated says nothing about apiEndpoint. Field-name hardening misses aliases.
6. Audit siblings of guarded tools. One allowlisted fetcher next to an unrestricted one is the JPMorgan finding, and the unrestricted one defines your exposure.
7. Treat forks as new attack surface. The upstream AWS project never fetched caller-supplied URLs; the fork added the behavior without adding the check.

The disclosure wave is also not finished. Per TNW, five US federal MCP servers under GSA's Technology Transformation Services, covering Veterans Affairs benefits claims, CMS Blue Button, regulations.gov, USASpending and CDC PLACES, were reported on September 2 and remain in triage, with the VA server logging full unredacted error responses that can include a veteran's name, Social Security number, date of birth and address. A separate report on Japan's Digital Agency grants server also remains open. Mohiuddin presents the full set at MCPCon North America on October 23.

Where Datapace fits

An SSRF fix tells you where one server's egress check now lives. It does not tell you what your agents may do and access across every path into the data, which is a policy question before it is a patch question. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. If your agents already reach production data through an MCP server, safe AI database access is the conversation to have.

The checklist above is an afternoon of work for one server. The reason it keeps being skipped is the same reason it was skipped in web apps for a decade: the dangerous request is indistinguishable from the normal one until you ask where the address resolves. Seven security teams this year learned that the question has to be asked by the code, every time, at the last possible moment before the connection opens.

Sources

1. OpenCVE, CVE-2026-14540 (description, affected product and 0.3.0 to 1.4.0 range, CVSS v4.0 8.0 by Google CNA and v3.1 6.1 by NVD, CWE-918, July 31 2026 publication, PR #3448 as the patch reference).
2. Syed Anas Mohiuddin, Four vendors, one bad assumption: SSRF in MCP servers (the Go http.Client redirect and IP-validation detail, fix merge and release dates, the mcp-server-fetch get_prompt bypass and May 25 Full Disclosure date, the Weaviate apiEndpoint finding and fix dates, the trusted-caller quote, the protocol pivoting definition).
3. The Next Web, Google, JPMorgan and two governments fixed the same MCP flaw (October 6 2026: the JPMorgan, DINUM and Tangerang findings, the DNS rebinding guard in the Google fix, the five GSA servers and VA logging detail, the Japan Digital Agency report, the A2A pivoting description and Markus Vervier's characterization, MCPCon October 23).
4. Go standard library, net/http documentation ("If CheckRedirect is nil, the Client uses its default policy, which is to stop after 10 consecutive requests").