Palo Alto Networks Unit 42 has disclosed a vulnerability in the Google Cloud Vertex AI SDK for Python that let an attacker with zero access to a victim’s project hijack the victim’s machine-learning model upload and execute code inside Google’s managed serving infrastructure. The technique, dubbed “Pickle in the Middle,” was reported through Google’s Vulnerability Reward Program on March 5, 2026, and fully patched in google-cloud-aiplatform v1.148.0 on April 15. Unit 42 published the write-up on June 16. There is no CVE assigned as of publication, and Unit 42 observed no exploitation in the wild.
The only prerequisites for the attacker were a Google Cloud project of their own and the victim’s project ID — which is frequently public. No credentials, no phishing, no foothold in the target.
How the attack works
When you call Model.upload() without setting staging_bucket, older versions of the SDK generated a predictable temporary Cloud Storage bucket name from the project ID and region — something like <project>-vertex-staging-<region>. The SDK checked whether that bucket existed, but never checked who owned it.
Cloud Storage bucket names are globally unique, so an attacker who knows the target’s project ID can pre-create the expected bucket in their own project. The victim’s SDK then uploads the model artifacts straight into the attacker’s bucket. From there, the attacker swaps the uploaded model for a malicious one.
This is where the pickle comes in. Most Python ML models are serialized with pickle or joblib, both of which execute code on load. When Vertex AI later pulls the model and deserializes it inside the serving container, the attacker’s payload runs.
The catch is timing. Unit 42 measured roughly 2.5 seconds between the victim’s upload and Vertex AI reading the file. Their proof of concept used a Cloud Function that fired on object-create and replaced the model in 1.4 seconds — comfortably inside the window.
Blast radius
The payload pulled an OAuth token from the serving container’s metadata server. In Unit 42’s test environment that token was not scoped to the compromised deployment. It reached other artifacts in the same Google-managed tenant project: a full TensorFlow model with trained weights, plus BigQuery metadata, access lists, tenant logs, GKE cluster names, and internal container image paths. A single hijacked upload became a cross-tenant information-disclosure and model-theft primitive.
Two conditions had to hold: the victim’s default staging bucket did not already exist in that region (common for a fresh project), and the developer left staging_bucket unset (common when relying on SDK defaults).
What to do now
Update google-cloud-aiplatform to 1.148.0 or later. The initial fix in v1.144.0 (March 31) only added a random uuid4 to the bucket name; the complete fix in 1.148.0 added bucket-ownership verification in Model.upload().
Because the flawed logic lives in the client SDK, the production service version is not the whole story. Audit the SDK version everywhere it runs — notebooks, CI jobs, scheduled retraining, and training pipelines, not just production endpoints. And set an explicit staging_bucket pointing at a Cloud Storage location you control, rather than trusting the generated default.
This is the second predictable-bucket-name flaw in Vertex AI this year. Google patched CVE-2026-2473 in February — a separate bucket-squatting bug in Vertex AI Experiments that likewise enabled cross-tenant code execution, model theft, and poisoning (see Google’s Vertex AI security bulletins). If you run anything on Vertex AI, treat staging-bucket naming as an attack surface, not an implementation detail.
References: Unit 42, “Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE”; The Hacker News coverage; google-cloud-aiplatform v1.148.0 release; Google Vertex AI security bulletins.