Disclosure timeline for googleapis/mcp-toolbox Origin validation

--- title: "The MCP spec requires Origin validation. Google's MCP server doesn't. It's been seven months." date: 2026-06-05 summary: "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." slug: google-mcp-origin-validation-seven-months author: "Damiën Semler" hero_glyph: brackets --- 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](https://github.com/googleapis/mcp-toolbox) (the official MCP integration for BigQuery, Cloud SQL, and AlloyDB), [does not implement that check](https://github.com/googleapis/mcp-toolbox/issues/3113). 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](https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/)) is the load-bearing fact. The bug is small. The dwell time is the story. ## 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](https://www.varonis.com/blog/model-context-protocol-dns-rebind-attack) 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](https://github.com/modelcontextprotocol/rust-sdk/issues/822) 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](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html) 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](https://cloud.google.com/blog/products/ai-machine-learning/mcp-toolbox-for-databases-now-supports-model-context-protocol) 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](https://github.com/modelcontextprotocol/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](https://agenstry.com/blog/mcp-spec-vs-probe-evidence) 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](https://agenstry.com). ## What we're watching Three things, observable in the next two quarters: 1. **Whether [issue #3113](https://github.com/googleapis/mcp-toolbox/issues/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](https://github.com/modelcontextprotocol/registry) 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 - [Default DNS-rebinding protection allows all domains by defaults — googleapis/mcp-toolbox issue #3113](https://github.com/googleapis/mcp-toolbox/issues/3113) — Jonathan Leitschuh, April 22, 2026. - [Understanding and Defending Against the Model Context Protocol DNS Rebind Attack](https://www.varonis.com/blog/model-context-protocol-dns-rebind-attack) — Varonis Threat Labs, March 24, 2026. - [Add Origin header validation for defense-in-depth in Streamable HTTP server — modelcontextprotocol/rust-sdk issue #822](https://github.com/modelcontextprotocol/rust-sdk/issues/822) — April 22, 2026. - [MCP Toolbox for Databases now supports Model Context Protocol](https://cloud.google.com/blog/products/ai-machine-learning/mcp-toolbox-for-databases-now-supports-model-context-protocol) — Google Cloud Blog, 2026. - [MCP Is Now Enterprise Infrastructure: Everything That Happened at MCP Dev Summit North America 2026](https://aaif.io/blog/mcp-is-now-enterprise-infrastructure-everything-that-happened-at-mcp-dev-summit-north-america-2026/) — Agentic AI Foundation, April 13, 2026. - [googleapis/mcp-toolbox on GitHub](https://github.com/googleapis/mcp-toolbox) — Google APIs, accessed May 2026. - [Vulnerability Disclosure Policy](https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html) — Google Project Zero, accessed May 2026.