Three MCP security failures checked the wrong bucket, path or network origin

An MCP integration may be authenticated and still perform an unsafe operation if it has not established which concrete resource it is using. Three advisories in the October research set concern different objects: a cloud bucket, a local filesystem path, and the origin receiving an HTTP redirect. Their fixes are not interchangeable.

The Cloud Run MCP case concerns a deployment workflow that used a predictable Cloud Storage bucket name formed from a project identifier. A different cloud principal could preclaim the globally unique name. If the deployment tool trusted the name without validating its owner, it could upload project artifacts to a bucket outside the intended project. The corrected release, 1.11.0, added an owner check and randomized fallback. The reported chain is a bucket-identity error, not proof of a real victim's source leak.

Google MCP Toolbox, by contrast, exposed tools that could access local paths or choose destination buckets using the server's ambient privileges. Version 1.5.0 introduced configuration limits such as allowedLocalRoots and allowedBuckets, but unrestricted defaults mean installing that release alone may not set the expected deployment policy. Authorization of the caller and allowlisting of the actual path and bucket are distinct checks.

A third case, the MCP TypeScript client redirect flaw, tracks credentials across an origin change. Standard Fetch behavior may drop an Authorization header while forwarding custom credential headers, or preserve sensitive body fields under 307 or 308 redirects. Corrected client and SDK releases address this cross-origin transport problem. It is neither a bucket preclaim nor local path traversal.

"MCP" is a protocol integration description, not one security boundary. The controlling process may have filesystem access, cloud credentials and an HTTP client, each with different defaults and lifecycle. Testing one of these controls does not test the other two. A service-side permission check cannot retroactively prevent a client from leaking a refresh token during discovery or redirection.

The shared engineering requirement is to bind each effect to the intended principal, resource identifier and operation at its real execution point. The advisories establish code-level defects and vendor repairs; they do not collectively establish production exploitation or one universal MCP escape primitive.

Relevant evidence: Cloud Run advisory, Toolbox advisory and SDK advisory.