Google Vertex AI SDK Flaw Allows Attackers to Shoot Model with Bucket Squatting
A flaw in the Google Cloud Vertex AI SDK for Python allows an attacker without access to the victim’s project to hijack the victim’s machine learning model and load and execute code within Google’s infrastructure.
Palo Alto Networks Unit 42, which found and reported the bug through the Google bug bounty program, calls this process “Pickle In The Middle” and said it didn’t see any exploits in the wild. Google has removed it; if you’re using the SDK, update to version 1.148.0 or later.
The attacker only needed his Google Cloud project and the victim’s project ID, which is usually public. No evidence, no phishing, no target capture.
The bug was how the SDK chose a temporary Cloud Storage bucket to load the models. If the user has not configured the bucket, the SDK generates a guessable name from the project ID and location, such as project-vertex-stage-region. It checks if that bucket exists, but not if it’s owned.
Because bucket names are globally unique, an attacker can create an expected bucket first in his project. The victim’s SDK will then load the model files into the attacker’s bucket. The attacker can then replace the loaded model with a malicious one.
Most Python ML models are saved with pickle or joblib, which can run the code when the file is loaded. When Vertex AI later loaded the modified model, the attacker’s code was placed inside the deployment container.
The attack depended on speed. Unit 42 measured about 2.5 seconds between the victim loading and the Vertex AI reading the file. In its proof-of-concept, the attacker used a Cloud Job that launched after uploading and changed the model in 1.4 seconds, before the Vertex AI could read it.
The payload then steals the OAuth token from the metadata server of the serving container and sends it to the attacker. In the Unit 42 testing environment, that token is not limited to vulnerable use. It can access other model artifacts in the same Google-managed tenant project, including a full weighted TensorFlow model, as well as BigQuery metadata, access lists, tenant logs, GKE cluster names, and internal container image methods.
The attack worked only under certain conditions: the victim’s platform bucket was not in that region, and the victim left stage_bucket parameter is not set. The first is typical of a new project in the Vertex AI region.
The second depends on the developer relying on SDK defaults rather than inventing their own bucket.
Unit 42 reported the bug to Google’s Vulnerability Rewards program on March 5, 2026. It tested versions 1.139.0 and 1.140.0, the latest available at the time, and found both to be vulnerable.
Google shipped the first fix in v1.144.0 on March 31, adding a random uuid4 to the bucket name. Finished a fix in v1.148.0 on April 15, added bucket ownership validation to prevent bucket swing in Model.upload(). As of publication, neither Unit 42 nor Google’s Vertex AI security patches list a CVE for this issue.
Update to 1.148.0 or later for identity checking to work. Also, set a transparent staging_bucket to the Cloud Storage you manage when uploading models. Because the debug logic resides in the client SDK, test the google-cloud-aiplatform version wherever it runs, including notebooks, CI jobs, and training pipelines, not just production services.
It is the second predicted error-bucket name to appear in Vertex AI this year. Google patched CVE-2026-2473 in February, a separate bucket-rolling bug in Vertex AI Experiments that also allowed for hacker code execution, model theft, and poisoning.
Unit 42’s previous work on Vertex AI automated service agent permissions followed a relative path from the deployed AI agent to customer and tenant data.
