What the Vertex AI Bucket Squatting Vulnerability Involved
The Vertex AI security vulnerability in Google’s Python SDK was a bucket squatting attack that allowed model hijacking by exploiting predictable Cloud Storage bucket names and unsafe model loading behaviors in AI pipelines. In this flaw, the SDK’s Model.upload() method could send a victim’s machine learning model to an attacker-controlled bucket, which then supplied a malicious model that Vertex AI loaded inside Google’s own serving infrastructure. Palo Alto Networks Unit 42, which disclosed the issue through Google’s bug bounty program, said it required no credentials or access to the victim’s project beyond knowing its public project ID. The weakness affected SDK versions such as 1.139.0 and 1.140.0 and has now been patched in v1.148.0, which adds stronger protections against bucket squatting and compromised model artifacts, closing off a worrying model hijacking and code execution path in production AI workflows.
How Bucket Squatting Enabled Model Hijacking in Vertex AI
Bucket squatting attacks exploit globally unique, predictable storage bucket names: whoever creates the bucket first owns it, regardless of who later expects to use it. The Vertex AI SDK previously generated default staging buckets from a project ID and region, producing names like project-vertex-staging-region. It checked if the bucket existed but never confirmed that the victim owned it. An attacker only needed their own cloud project and the victim’s project ID to pre-create that bucket. When the victim ran Model.upload() without setting staging_bucket, the SDK uploaded model files into the attacker’s bucket. The attacker could then swap the model with a malicious pickle or joblib file. According to Palo Alto Networks Unit 42, this allowed “an attacker with no access to a victim’s project [to] hijack the victim’s machine learning model upload and run code inside Google’s serving infrastructure.”
From Model Swap to Code Execution and Token Theft
The attack chain turned a bucket squatting attack into code execution inside the Vertex AI serving environment. Many Python models are serialized with pickle or joblib, both capable of executing arbitrary code when deserialized. Once the victim uploaded to the attacker-controlled bucket, a proof-of-concept Cloud Function reacted to the upload and replaced the file within 1.4 seconds. Unit 42 measured only about 2.5 seconds between upload and Vertex AI reading the model, leaving a narrow but reliable window to inject a malicious artifact. When Vertex AI later loaded the swapped model, the payload executed inside the serving container, grabbed an OAuth token from the metadata server, and exfiltrated it. In Unit 42’s tests, that token was not limited to the single deployment: it could access other model artifacts, BigQuery metadata, access lists, logs, GKE cluster names, and internal image paths within the same Google-managed tenant project.
Google’s Patch: Randomized Buckets and Ownership Checks
Google responded with a two-step fix in the Vertex AI SDK. Version 1.144.0 changed the default staging bucket pattern by appending a random uuid4 value, removing the predictable naming that bucket squatting attacks depend on. Version 1.148.0 completed the fix by adding explicit bucket ownership verification to Model.upload(), blocking attacker-owned buckets even if they somehow match the expected name. Users are urged to upgrade to 1.148.0 or later so the ownership check is active. The vulnerable behavior sat entirely in the client SDK, which means every environment that calls google-cloud-aiplatform needs review: notebooks, CI pipelines, model training jobs, and batch scripts, not just production services. Setting an explicit staging_bucket pointing to a bucket you control further reduces exposure by removing reliance on SDK-generated defaults that were previously exploitable for model hijacking and remote code execution.
AI Supply Chain Risk and Lessons for SDK Users
This Vertex AI security vulnerability highlights a broader SDK supply chain risk for AI development: trust in default infrastructure choices can expose hidden attack surfaces. Here, a convenience feature—automatic staging bucket selection—quietly opened a model hijacking path that reached deep into Google-managed tenant projects. The incident mirrors trends in other ecosystems, where cooldowns and staged releases try to slow down supply chain attacks on extensions and packages, as seen in moves like VS Code’s delayed auto-updates and configurable dependency age checks in language package managers. For AI teams, the main lessons are clear: never assume defaults are safe, lock model loading to safer formats where possible, and treat SDKs as critical dependencies that must be version-pinned, regularly audited, and upgraded in every environment. Combining explicit bucket configuration, strict artifact controls, and timely SDK updates is now part of basic hygiene for secure AI pipelines.
