A flaw in the Google Cloud Vertex AI SDK for Python allows an attacker without access to a victim’s project to hijack the victim’s machine learning model uploads and execute code within Google’s service delivery infrastructure.
Palo Alto Networks Unit 42, which discovered and reported the bug through Google’s bug bounty program, called this technique “pickle in the middle”, and stated that he had not seen any actual abuse. Google has applied a patch. If you are using the SDK, please update to version 1.148.0 or later.
All the attackers needed was their Google Cloud project and the victim’s project ID, which is often publicly available. No credentials, no phishing, no stepping stones to the target.
The problem was in how the SDK chooses a temporary Cloud Storage bucket for model upload. If you don’t configure a bucket, the SDK generates a predictable name from your project ID and region. Project apex staging area. It was confirmed that the bucket existed, but it was not confirmed that the victim owned it.
Bucket names are globally unique, so an attacker could create the first expected bucket in their project. The victim’s SDK uploads the model file to the attacker’s bucket. An attacker could then replace the uploaded model with a malicious one.
Many Python ML models are saved with pickle or joblib, which allows you to run code when the file loads. The attacker’s code then ran within the serving container when Vertex AI loaded the swapped model.
Attacks depended on speed. Unit 42 measured the time it took for Vertex AI to read the file from the time the victim uploaded it to approximately 2.5 seconds. In a proof of concept, the attacker used a Cloud Function that was triggered after upload and replaced the model in 1.4 seconds before Vertex AI could read it.
The payload then steals an OAuth token from the serving container’s metadata server and sends it to the attacker. In Unit 42’s test environment, that token was not limited to compromised deployments. May access other model artifacts within the same Google-managed tenant project. This includes the complete TensorFlow model with trained weights, BigQuery metadata, access lists, tenant logs, GKE cluster name, and internal container image path.
This attack only worked under certain conditions. This means that the victim’s default staging bucket does not yet exist in that region, and the victim has left the region. staging_bucket Parameter settings will be canceled. The first is common to new projects in Vertex AI within a region.
The second relies on developers not naming their own buckets but relying on SDK defaults.
Unit 42 reported this flaw on March 5, 2026 through Google’s Vulnerability Reward Program. We tested versions 1.139.0 and 1.140.0, the latest versions available at the time, and found that both were vulnerable.
Google released an initial fix for v1.144.0 on March 31st, adding a random uuid4 to the bucket name. The fix was completed in v1.148.0 on April 15th and added bucket ownership validation to block bucket squatting in Model.upload(). At the time of publication, neither Unit 42 nor Google’s Vertex AI security bulletin lists any CVEs for this issue.
Update to 1.148.0 or later so ownership checks are active. Also, when you upload your model, set an explicit staging_bucket to the Cloud Storage location you control. The faulty logic resides in the client SDK, so check the version of google-cloud-aiplatform wherever it’s running, including in your notebooks, CI jobs, and training pipelines, not just your production services.
This is the second predictable bucket name flaw to surface in Vertex AI this year. Google patched CVE-2026-2473 in February. This was another bucket-hogging bug in Vertex AI Experiments that also allowed for cross-tenant code execution, model theft, and poisoning.
Unit 42’s previous work on Vertex AI’s default service agent permissions tracked the relevant paths from deployed AI agents to customer and tenant data.
