A deployment agent needs staging storage to build a service, but global bucket-name availability is not evidence of ownership. The vulnerable helper could use a deterministic name and proceed without binding that bucket to the intended Google Cloud project number. The resulting staging upload crossed a cloud tenant boundary before an application container…
Inspect the ClaimsCase · DiggingBeagle record
Cloud Run MCP deployment could upload project source to a preclaimed bucket
A Google Cloud Run MCP deployment helper derived a predictable global storage name without checking its owner. Version 1.11.0 adds owner verification and a randomized fallback.
MCP control-plane exposureAgent isolation requires bounding indirect outbound authority through allowed services
Scope
The attacker must preclaim the particular globally unique bucket name and encounter a susceptible deployment path. The advisory documents a vulnerability rather than confirming affected customer deployments or source theft in the wild.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- not established
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
Enrich update: CLM-ENRICH-20261027-07 cites SRC-2026-CP21-CLOUDRUN-MCP-BUCKET-SQUAT at CVE-2026-85297, Description and references to v1.11.0 release. New evidence concerns the bounded reported mechanism, prerequisite or outcome; setting research_demonstration; exploit status not_established; remediation status patch_available. No independently comparable impact scale, affected production population or universal exploit success measure was established, so the impact band remains null. Original Claims remain individually attributable and any observed incident or simulated result is distinguished in the narrative.
Assessed Oct 27, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-ENRICH-20261027-07 · CVE-2026-85297: Cloud Run MCP cloud build bucket ownership validation
At a glance
A coding agent that correctly asks a tool to deploy code still depends on the tool verifying the identity of storage it contacts.
Read the implicationsThe attacker must preclaim the particular globally unique bucket name and encounter a susceptible deployment path. The advisory documents a vulnerability rather than confirming affected customer deployments or source theft in the wild.
Limits and uncertaintyFull account
A deployment agent needs staging storage to build a service, but global bucket-name availability is not evidence of ownership. The vulnerable helper could use a deterministic name and proceed without binding that bucket to the intended Google Cloud project number. The resulting staging upload crossed a cloud tenant boundary before an application container was even deployed.
The advisory reports that an attacker could precreate the globally unique Cloud Storage bucket expected by cloud-run-mcp and cause subsequent project files to be uploaded to a bucket it controlled. The patched version is 1.11.0. The attacker must preclaim the particular globally unique bucket name and encounter a susceptible deployment path. The advisory documents a vulnerability rather than confirming affected customer deployments or source theft in the wild.
Upgrade to cloud-run-mcp 1.11.0 and verify bucket ownership against the project identity, using randomized project-owned staging names when a collision exists. A coding agent that correctly asks a tool to deploy code still depends on the tool verifying the identity of storage it contacts. Primary evidence.
Additional evidence and trust boundary
A deterministic bucket name is only an address, not a trustworthy project ownership assertion. A cloud deployment assistant that uploads build inputs to a pre-existing bucket must establish that the bucket belongs to the intended cloud principal before transferring source code. Upgrade and independently check ownership of any pre-existing staging bucket; a private or unguessable project name is not an adequate authorization control. Supporting record.
Mechanism and trust boundary
- 01
Step
- 02
Step
- 03
Step
Timeline
- Oct 26, 2026disclosure
Public disclosure
Claims & evidence
CLM-ENRICH-20261027-07The public advisory names Cloud Run MCP versions before 1.11.0 as susceptible to bucket squatting and instructs deployments to upgrade, but does not enumerate exploited cloud projects or victims.supported
Basis: reported finding
- supportsCVE-2026-85297: Cloud Run MCP cloud build bucket ownership validationprimary disclosure
CVE-2026-85297, Description and references to v1.11.0 release
CLM-CP21-CLOUDRUN-MCP-BUCKET-SQUAT-1The advisory reports that an attacker could precreate the globally unique Cloud Storage bucket expected by cloud-run-mcp and cause subsequent project files to be uploaded to a bucket it controlled. The patched version is 1.11.0.supported
Basis: reported finding
- supportsCVE-2026-85297: Cloud Run MCP cloud build bucket ownership validationprimary disclosure
Description, predictable bucket calculation, remediation and patched version
Implications
A coding agent that correctly asks a tool to deploy code still depends on the tool verifying the identity of storage it contacts.
Controls and mitigations
- Upgrade to cloud-run-mcp 1.11.0 and verify bucket ownership against the project identity, using randomized project-owned staging names when a collision exists.
Unknowns and contradictions
- The attacker must preclaim the particular globally unique bucket name and encounter a susceptible deployment path. The advisory documents a vulnerability rather than confirming affected customer deployments or source theft in the wild.
Sources and citation
Material revision history
- Oct 27, 2026 · Canonical change recorded · new in release · revision 196