All posts
· 10 min read ·

The MCP spec requires Origin validation. Google's MCP server doesn't. It's been seven months.

Jonathan Leitschuh disclosed a DNS-rebinding flaw in Google's official MCP database server on October 14, 2025. The MCP spec is unambiguous about requiring Origin header validation. The reference SDK ships it. Google's implementation does not, seven months later.

A field report, narrow on purpose. The Model Context Protocol specification (versions 2025-06-18 and 2025-11-25) requires HTTP transports to validate the Origin header on every incoming connection and respond with HTTP 403 if it is invalid. The clause exists in both spec revisions, with identical wording, in the section titled "Security Warning." Google's MCP server for databases, googleapis/mcp-toolbox (the official MCP integration for BigQuery, Cloud SQL, and AlloyDB), does not implement that check. Jonathan Leitschuh disclosed the issue to Google's Vulnerability Reward Program on October 14, 2025. The public GitHub issue (#3113) was filed on April 22, 2026. As of this writing on May 17, the issue is open. The patch is not in flight.

That gap (more than seven months from initial disclosure, more than a month after public demonstration at the MCP Dev Summit in April 2026) is the load-bearing fact. The bug is small. The dwell time is the story.

Disclosure timeline for googleapis/mcp-toolbox Origin validation Horizontal timeline from October 14, 2025 to May 17, 2026. Markers in order: October 14, 2025 — disclosed to Google's Vulnerability Reward Program; April 13, 2026 — publicly demonstrated at the MCP Dev Summit; April 22, 2026 — public GitHub issue #3113 filed; May 17, 2026 — still open. A pink bar shows the entire dwell time. A violet dashed line marks the 90-day Project Zero disclosure window for reference. DISCLOSURE TIMELINE · googleapis/mcp-toolbox Project Zero 90-day window Oct 14, 2025 VRP disclosure Apr 13, 2026 summit demo Apr 22, 2026 issue #3113 May 17, 2026 still open

DWELL TIME: 215 DAYS · STILL UNPATCHED

The mechanics, briefly

DNS rebinding is a 2007-vintage attack against services that bind to localhost and trust the network position of the caller. A malicious website serves DNS records that resolve to its own server first, then flip to an internal address (127.0.0.1, 192.168.x.x) for subsequent requests from the same browser. The browser's same-origin policy keys on the hostname, which has not changed, so the requests are treated as same-origin and proceed without challenge.

The mitigation is to validate either the Host header (which the browser cannot forge after rebinding) or the Origin header (which the browser attaches based on the originating page, not the rebound destination). Varonis Threat Labs notes the time-to-exploit on a vulnerable local MCP server in Chrome is roughly three seconds. The payload, per the GitHub issue, is full control: database manipulation, data theft, resource creation, arbitrary HTTP requests with the developer's credentials.

This is not a new attack pattern. The MCP specification anticipates it by name and prescribes the mitigation. The MCP Rust SDK shipped Host header validation in v1.4.0 and is currently adding Origin validation as defense-in-depth. The reference implementations have done the work the spec requires. The Google toolbox has not.

What the spec actually says

The relevant clause, reproduced from the MCP base protocol's Transports section, version 2025-11-25:

Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks. If the Origin header is present and invalid, servers MUST respond with HTTP 403 Forbidden.

The "MUST" keywords are RFC 2119 normative language. Strictly read, an MCP server that does not validate Origin is non-conformant with the specification it advertises support for. A consumer reading googleapis/mcp-toolbox's documentation would have no way to distinguish that gap from the prose claim of MCP compliance.

Why the dwell time matters more than the bug

A missing Origin check is a one-line fix in essentially any HTTP framework. The vulnerability itself is not the interesting object. The interesting object is the operational shape of an ecosystem in which:

  1. The most prominent enterprise MCP server for databases is shipped by Google.
  2. The MCP specification is unambiguous about the required mitigation.
  3. The reference SDK has shipped the mitigation.
  4. A working exploit has been demonstrated publicly.
  5. The patch has not landed.

The standard responsible-disclosure window in Google's own Project Zero disclosure policy is 90 days for similarly classed bugs. Leitschuh waited 181 days before public demonstration. The public GitHub issue arrived another 9 days after that. None of that has produced a fix. The bug now has dwell time greater than two full Project Zero windows.

The structural read is that MCP infrastructure is inheriting the operational realities of every other large vendor's open-source side project: low-priority bugs in non-flagship repositories get patched on the timeline that the maintaining team has bandwidth for, regardless of spec compliance or the size of the install base downstream. Google's MCP Toolbox for Databases is an open-source side project. It is also, as of May 2026, the most prominent route by which an enterprise agent reaches Google Cloud's managed databases.

What this means for registries that index MCP servers

A consumer reading the AAIF MCP Registry for an MCP server entry sees self-declared metadata: capabilities, transport mode, documentation pointers. They do not see whether the server validates Origin. They do not see whether the server has an open security issue against it. They do not see how long any disclosed vulnerability has been unpatched.

The MCP Registry could publish all three of those signals. So could any downstream service that consumes the registry's data. None of these signals require a new specification — they require the registry layer to do the work of probing the published servers and attaching the results to the listing.

This is the same observation our earlier post made about the population scans of MCP servers that found command injection in roughly a third of them. That post made the argument by aggregation: the population data refutes the protocol-level claim. This post makes the same argument by case study: a single named server, owned by one of the largest enterprise vendors, is non-conformant with the specification in a documented and demonstrated way, and the consumer reading the registry has no way to know it.

A registry that publishes "this server claims MCP compliance" tells you nothing about issue #3113. A registry that publishes "this server, when probed today, responded to a DNS-rebinding test pattern" tells you what you actually need to make a decision. The first registry exists. The second is the work we publish.

What we're watching

Three things, observable in the next two quarters:

  1. Whether issue #3113 closes with a patch. A specific landing date will be a useful data point for how long high-visibility MCP vulnerabilities in flagship enterprise repos take to address.
  2. Whether the AAIF MCP Registry adopts a probe-driven security field. A boolean for "validates Origin header" or, more usefully, a timestamp of last conformance test against the protocol's MUSTs would close the gap between published claim and verified behavior.
  3. Whether other large vendors' MCP servers fail the same probe. A population scan of the top hundred MCP servers for compliance with the Transports Security Warning section would produce a number that either supports or refutes the googleapis/mcp-toolbox pattern at scale.

The headline read of this story is "Google has an unpatched MCP bug." That framing is correct and is the smallest interesting version. The more useful read is that an enterprise-grade MCP server, published by a tier-one vendor, can be out of compliance with a normative MUST in the protocol it advertises for over seven months without that fact being visible to the consumers who depend on it. The registry layer is where that visibility is supposed to live. As of May 2026, it doesn't.

Sources

← Back to blog Agenstry