Bucket Squatting in Vertex AI SDK Opened Cross-Tenant RCE Window
A staging-bucket naming flaw in two versions of Google's Vertex AI Python SDK let attackers pre-register a victim's expected bucket and swap in a malicious pickle model before the platform could retrieve the original.
Unit 42 researchers disclosed a design flaw in the Vertex AI SDK for Python that, in versions 1.139.0 and 1.140.0, made cross-tenant remote code execution theoretically achievable through a combination of predictable bucket naming and absent ownership validation.
The root cause is structural. The SDK derived staging bucket names exclusively from a customer's project ID and region. When the SDK checked whether that bucket existed, it confirmed existence only — not ownership. An attacker who knew a victim's project ID and region could pre-create the matching bucket name inside their own Google Cloud project and wait.
This is what researchers termed "Bucket Squatting." Cloud storage bucket names are globally unique across all of Google Cloud. That uniqueness, intended as a convenience guarantee, becomes an attack surface when the consuming SDK never verifies it holds the bucket in question.
Once a model artifact landed in the attacker-controlled bucket, a narrow race-condition window opened. The attacker could substitute the legitimate artifact with a poisoned replacement before Vertex AI's service agent retrieved it for deployment. Researchers named this stage of the attack "Pickle in the Middle," referencing the deserialization format involved.
Python machine learning models are commonly serialized using pickle or Joblib. Pickle deserialization executes arbitrary code through specially crafted objects by design — there is no safe way to deserialize untrusted pickle data. A poisoned model file, loaded by Vertex AI's serving infrastructure, would therefore produce code execution across tenant boundaries.
Google modified the affected workflow so that staging buckets are now validated before use, blocking pre-registration by outside parties. Fixes shipped in SDK versions 1.144.0 and 1.148.0. Users running either vulnerable version should upgrade immediately to one of the patched releases.
Unit 42 also noted that the vulnerability was identified with LLM assistance integrated into the code-analysis workflow. Researchers described iteratively narrowing the model's focus toward resource-provisioning paths influenced by user-controlled or project-derived inputs — a methodology they say compressed what previously took days into a materially shorter window.
Google did not provide a public statement on the disclosure timeline.
