A vulnerability in Google’s Vertex AI SDK for Python allowed an attacker without access to the victim’s project to take over the victim’s machine learning model, upload it, and execute code inside Google’s service infrastructure. Palo Alto Networks Unit 42 discovered and reported the flaw through Google’s bug bounty program, referring to the technique as “Pickle in the Middle.”
See also: PCPJack: Attack on 230 AWS, Google Cloud and Azure cloud servers
They noted that there was no evidence of active exploitation. Google has already patched the vulnerability; users of the Google Vertex AI SDK are advised to upgrade to version 1.148.0 or later.
The attacker only needed a Google Cloud project of their own and the victim's project ID, which is often public. No credentials, phishing, or access to the target were required. The vulnerability was related to the way the SDK selected a temporary Cloud Storage bucket for model uploads. If the user did not specify a bucket, the SDK generated a predictable name based on the project ID and region, such as project-vertex-staging-region.
It checked for the existence of this bucket but did not verify whether the bucket belonged to the victim. Since bucket names are globally unique, an attacker could create the expected bucket in their own project. As a result, the victim's SDK would upload the model files to the attacker's bucket, allowing the attacker to replace the uploaded model with a malicious one.
Many ML Python models are stored using pickle or joblib, which can execute code when a file is loaded. When Vertex AI later loaded the replaced model, the attacker's code was executed inside the serving container. The attack relied on speed. Unit 42 measured about 2.5 seconds between the victim's upload and the Google Vertex AI SDK reading the file.
In their proof of concept, the attacker used a Cloud Function that was triggered after the upload and replaced the model in 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, this token was not limited to the compromised deployment; it could access other model objects in the same Google-managed tenant project, including a full TensorFlow with trained weights, as well as BigQuery, access lists, tenant logs, GKE cluster names, and internal container image paths.
See also: Vertex AI vulnerability exposes Google Cloud data and files
The attack depended on specific conditions: the victim's default staging bucket did not already exist in that region, and the victim left the staging_bucket undefined. The first condition is common for new Vertex AI in a region, while the second relies on the developer using the SDK's default instead of specifying their own bucket. Unit 42 reported the vulnerability through Google's Vulnerability Bounty Program on March 5, 2026.
They tested versions 1.139.0 and 1.140.0, the latest available at the time, and found both vulnerable. Google released an initial fix in version v1.144.0 on March 31, adding a random uuid4 to the bucket name. The full fix was implemented in version v1.148.0 on April 15, which included bucket ownership verification to prevent bucket squatting in Model.upload().
As of publication, neither Unit 42 nor Google's Vertex AI security bulletins had listed a CVE for the issue.
Users are advised to upgrade to version 1.148.0 or later to ensure ownership checking is active. Additionally, they should set an explicit staging_bucket to a Cloud Storage location that they check when uploading models. Given that the flawed logic is in the client SDK, it is important to check the google-cloud-aiplatform version wherever it is running, including notebooks, CI jobs, and training pipelines, not just in production services.
See also: TrueConf: Zero-day vulnerability used in attacks on government networks
This is the second predictable bucket name vulnerability to surface in Vertex AI this year. Google patched CVE-2026-2473 in February, which was a separate bucket-squatting vulnerability in Vertex AI Experiments that also allowed cross-tenant code execution, model theft, and poisoning. Unit 42’s previous work on Vertex AI’s default service-agent permissions detected a related path from a deployed AI agent to customer and tenant data.
