Bucket Squatting in Vertex AI SDK Opened Cross-Tenant RCE Window

Key points

• Versions 1.139.0 and 1.140.0 of the Vertex AI Python SDK derived staging bucket names from project ID and region alone, with no ownership check.
• An attacker knowing those two values could pre-create the matching bucket name inside their own Google Cloud project and wait.
• Once a model artifact arrived, a narrow race window let the attacker swap it for a poisoned pickle file before Vertex AI's service agent retrieved it.
• Pickle deserialization executes arbitrary code by design; a poisoned model loaded by serving infrastructure produces cross-tenant code execution.
• Fixes shipped in SDK versions 1.144.0 and 1.148.0; upgrade immediately.

What made the naming logic exploitable?

The flaw is structural. Staging bucket names came exclusively from a customer's project ID and region. When the SDK found a bucket with the matching name already existed, it confirmed only existence, not ownership. Because no two buckets across all of Google Cloud can share a name, an attacker who could predict that name could register it first inside their own project. Any later attempt by the victim's SDK to use that bucket silently fell back to the attacker's copy. Unit 42 called this "Bucket Squatting."

How did code execution follow?

Once a model artifact landed in the attacker-controlled bucket, a race window opened. Before Vertex AI's service agent retrieved the file for deployment, the attacker could swap the legitimate artifact for a poisoned replacement. Python ML models are routinely serialized with pickle or Joblib. Pickle deserialization executes arbitrary code through specially crafted objects by design, so there's no safe path for loading untrusted data. Unit 42 named this stage "Pickle in the Middle." Our June coverage of the original disclosure has the full attack chain.

Should you worry if you haven't patched yet?

Yes. Google modified the affected workflow so staging buckets are validated before use, blocking pre-registration by outside parties, but that protection only reaches you once you've upgraded. Patches shipped in versions 1.144.0 and 1.148.0. If you're still on 1.139.0 or 1.140.0, you're exposed to any attacker who already knows your project ID and region, two values that aren't exactly secrets.

What role did AI play in finding this?

Unit 42 integrated an LLM into its code-analysis workflow. Researchers told the original outlet that analysis which once took days can now run significantly faster, by iteratively narrowing the model's focus toward resource-provisioning paths influenced by user-controlled or project-derived inputs. The practical implication is unsettling: the same compression of effort available to defenders is available to anyone running a comparable workflow against your SDK dependencies.

Google did not respond publicly to requests for comment on the disclosure timeline. Watch for whether Google formalises its bucket-ownership validation as a standing SDK requirement rather than a one-off patch; if it doesn't, the same class of flaw could resurface in any workflow that allocates cloud resources by name alone.