vulnerability writeup

SSRF in Google's MCP Toolbox for Databases

Summary

Google's MCP Toolbox for Databases lets an AI agent call out to HTTP endpoints as one of its configured tools. I found that the generic HTTP source's client didn't check where a request got redirected to before following it. An agent, or anything feeding input to the agent, could point that HTTP tool at an internal address, and the client would follow the redirect there without complaint.

That's a textbook Server-Side Request Forgery: the server (in this case the toolbox process) makes a request on an attacker's behalf to a destination the attacker chose, not the one the operator configured. On a cloud instance, the most direct target for that is the instance metadata service, which is exactly the kind of endpoint SSRF checks exist to keep off-limits.

This writeup covers the root cause, why it matters specifically for an MCP-connected agent, and how Google fixed it. I'm not publishing a working exploit chain against a live target; the technical detail here is enough for anyone running an affected version to understand and verify the fix, without functioning as a plug-and-play attack.

Why this matters for an agent, specifically

A normal web app with an SSRF bug already has a real problem. An MCP-connected agent makes it worse, because the input driving the HTTP call doesn't have to come from a form field a security team reviewed — it can come from a document, a webpage, or any other content the agent is asked to read. If a tool description or a piece of retrieved content can influence which URL the agent's HTTP tool ends up requesting (directly, or via a redirect the client blindly follows), the SSRF stops being "an attacker needs API access" and becomes "an attacker needs to get text in front of the model." That's a much lower bar, and it's the reason MCP security has become its own area of focus rather than a subset of ordinary web security.

Root cause

The vulnerable code lived in internal/sources/http/http.go. The toolbox does validate the path a caller supplies for a configured HTTP tool — it rejects an absolute URL, a different host, or path traversal in that parameter. What it didn't validate was where the request ended up after the operator-configured backend responded. Go's default http.Client follows redirects automatically unless you tell it not to; the toolbox's HTTP source never set a CheckRedirect policy, and nothing re-checked a redirect's destination IP against a blocklist of internal/private ranges before following it.

Practically: this isn't "attacker points the tool at their own server" — the base URL is fixed by the operator's config, and the path-parameter checks above already close that door. The real precondition is the configured backend itself issuing a redirect: an open-redirect endpoint on that backend, or a backend that's malicious or has been compromised. If either of those is true, the toolbox blindly follows the redirect to an internal address (a private IP, a loopback address, or a cloud metadata endpoint) and returns whatever comes back. No credential theft or injection into the toolbox itself is required — it's a missing check on redirect destinations, gated on the backend's own behavior.

Official vulnerability description

From the MITRE record, verbatim:

"A Server-Side Request Forgery (SSRF) vulnerability exists in the generic
HTTP source and tool components of Google mcp-toolbox versions 0.3.0
through 1.4.0. While the toolbox implements baseline input sanitization
for user-controlled parameters, the underlying HTTP client
(internal/sources/http/http.go) fails to safely regulate request
redirection boundaries. Specifically, the client is initialized without
a restrictive CheckRedirect policy hook and lacks target IP validation.
An attacker or a malicious data-driven prompt can supply a crafted path
parameter that triggers an open redirect or a direct destination swap
on the target backend, coercing the mcp-toolbox into blindly following
the redirection and making unauthorized requests to internal or
arbitrary external endpoints."

CVSS v4.0 breakdown

Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:U · Score: 8.0 (High)

The 8.0 is Google's own CVSS v4.0 score as CNA. NVD's independent analysis uses CVSS v3.1 and scores it 6.1 (Medium) — AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, reflecting the User Interaction requirement and the redirect precondition described above. Both scores are on the NVD record.

The fix

Google merged the fix as PR #3448, "fix(source/http): implement SSRF guard," shipped in v1.5.0. It adds a dedicated SSRF guard to the HTTP source rather than a narrow patch:

• Rejects a base URL that resolves directly to a blocked IP at startup (fail fast, not at request time)
• Re-checks every redirect target against a blocklist of private/non-routable IP ranges before following it — closing the exact gap this report was about
• Adds a Dialer.Control hook that re-checks the actual IP at connect time, guarding against DNS-rebinding style TOCTOU (time-of-check-to-time-of-use) bypasses of the redirect check
• Adds explicit configuration (allowPrivateNetworks, allowedIpRanges, customBlockedIpRanges) so operators who genuinely need to reach internal services can opt in deliberately, instead of the client defaulting to it
• Strengthens an existing TLS-verification warning to call out the MITM risk explicitly

Changes touched five files: the SSRF guard logic and its tests in internal/sources/http/http.go and http_test.go, integration tests in tests/http/, and updated docs at docs/en/integrations/http/source.md.

Disclosure timeline

1. before 06‑16Reported privately to Google; reproduction details and affected code path shared
2. 2026‑06‑16PR #3448 opened: SSRF guard for the HTTP source
3. 2026‑06‑18PR #3448 merged — body credits the report: "Reported by: Syed Anas Mohiuddin"
4. 2026‑06‑18Fix released in mcp-toolbox v1.5.0, same day
5. 2026‑07‑03CVE ID reserved with MITRE (Google as CNA)
6. 2026‑07‑31CVE-2026-14540 published, credited to me as finder

Google shipped the fix (June 18) before formally reserving the CVE ID (July 3) — the patch and the paper trail don't always move in lockstep. Exact report date is withheld here since it isn't published anywhere; every other date above is independently verifiable at the links below.

References

• Official MITRE CVE record: cve.org/CVERecord?id=CVE-2026-14540
• NVD entry: nvd.nist.gov/vuln/detail/CVE-2026-14540
• Fix PR: github.com/googleapis/mcp-toolbox/pull/3448
• Affected project: github.com/googleapis/mcp-toolbox

About me

I'm Syed Anas Mohiuddin, an AI security researcher based in New York. I built mcp-safeguard, an open-source scanner that checks MCP server code and tool descriptions for exactly this kind of gap — SSRF, prompt injection, credential exposure, and tool poisoning — before an agent ever connects to them. More about my work: syedanas01.github.io.