Skip to content
Cognivators
2026-10-18 · 5 min read

The MCP tool that followed a redirect: how CVE-2026-14540 worked

A walk through the SSRF in Google's MCP Toolbox: why an HTTP client with no redirect policy is dangerous when a model supplies the parameters, and what the fix changes.

Server-side request forgery is an old bug. What changes with MCP is who chooses the input. In a normal web app, a person types the URL or the path. In an MCP server, a model chooses it, and the model has just read whatever text an attacker managed to put in front of it.

What the toolbox did

Google's MCP Toolbox for Databases includes a generic HTTP source. In versions 0.3.0 through 1.4.0 its HTTP client was created without a restrictive redirect policy and without any check on the destination IP address. The toolbox did sanitize user-controlled parameters. It did not control where a response could send the client next.

A crafted path parameter could trigger an open redirect, or a direct swap of the destination, on the backend the toolbox was configured to call. The client followed it and made the request to an internal address or to any external one.

Why the model matters

The attacker never needs a shell on the toolbox host or a login to the toolbox. They need the model to pass along a parameter. A malicious document, a poisoned database row or a crafted support ticket is enough, because the model treats all of it as context. The toolbox then makes the call from inside your network.

What the fix changes

Google's fix, PR #3448 merged on 18 June 2026, adds an SSRFGuard. It protects against DNS rebinding, where a hostname resolves to a safe address when checked and to an internal one when used. It adds settings for private networks and IP ranges. It also checks the configured base URL when the source starts, so a bad configuration fails early instead of at the first request.

What to check in your own MCP servers

Look for any tool that makes an outbound request from a value the model can influence. Then ask three things. Does the HTTP client follow redirects, and to where? Is the destination address checked after DNS resolution, not before? Can the tool reach private ranges at all, and does it need to?

Google published the issue as CVE-2026-14540 on 31 July 2026 with a CVSS 4.0 score of 8.0. The record credits Syed Anas Mohiuddin as the finder.