A flaw in the Google Cloud Vertex AI SDK for Python allows an attacker, who does not have access to the victim’s project, to hijack the victim’s machine learning model upload and run the code inside Google’s serving infrastructure.
Palo Alto Networks Unit 42, which found and reported the bug through Google’s bug bounty program, described this technology as “pickle in the middle” and said it hasn’t seen any exploits in the wild. Google has patched it; if you use the SDK, update to version 1.148.0 or later.
The attacker only needed their own Google Cloud project and the victim’s project ID, which is often public. No credentialing, no phishing, no target penetration.
The flaw was how the SDK chose a temporary cloud storage bucket for model upload. If a user has not set up a bucket, the SDK generates a predicted name from the project ID and region, e.g. project-vertex-staging-area. It checked whether the bucket existed, but not whether the victim had it.
Because bucket names are globally unique, an attacker can first create the desired bucket in their project. The victim’s SDK will then upload the model files to the attacker’s bucket. The attacker can then replace the uploaded model with a malicious model.
Many Python ML models are saved with pickle or joblib, which can run code when the file is loaded. When Vertex AI subsequently loaded the swapped model, the attacker’s code got executed inside the serving container.
The attack depended on speed. Unit 42 measured approximately 2.5 seconds between the victim’s upload and Vertex AI reading the file. In their proof of concept, the attacker used a cloud function that was triggered after upload and transformed the model 1.4 seconds before Vertex AI could read it.
The payload then stole an OAuth token from the serving container’s metadata server and sent it to the attacker. In Unit 42’s test environment, that token was not limited to the compromised deployment. It can access other model artifacts in the same Google-managed tenant project, including full TensorFlow models with trained weights, as well as BigQuery metadata, access lists, tenant logs, GKE cluster names, and internal container image paths.
The attack only worked under specific circumstances: the victim’s default staging bucket did not already exist in that region, and the victim left it staging_bucket Parameter unset. The first is common for a new project in Vertex AI in any field.
Second, it’s up to the developer to name their buckets rather than relying on the SDK’s defaults.
Unit 42 reported the flaw through Google’s Vulnerability Rewards program on March 5, 2026. It tested the latest versions available at that time, 1.139.0 and 1.140.0, and found both to be vulnerable.
Google shipped an initial fix in v1.144.0 on March 31, which added a random uuid4 to the bucket name. It completed improvements to v1.148.0 on April 15, and added bucket ownership validation to prevent bucket squatting in models.upload(). At the time of publication, neither Unit 42 nor Google’s Vertex AI security bulletin lists a CVE for this issue.
Update to version 1.148.0 or later so that ownership checking remains active. Also, set an explicit staging_bucket to a cloud storage location you control when uploading models. Since the flawed logic resides in the client SDK, check the google-cloud-aiplatform version wherever it runs, including notebooks, CI jobs, and training pipelines, not just production services.
This is the second predicted-bucket-name flaw to surface in Vertex AI this year. Google in February patched CVE-2026-2473, a separate bucket-squatting bug in Vertex AI Experiments that also allows cross-tenant code execution, model theft, and poisoning.
Unit 42’s earlier work on Vertex AI’s default service-agent permissions explored related paths in customer and tenant data from a deployed AI agent.
