Pickle in the Middle a Vertex AI vulnerability that allows you to run code and steal models

A failure in the Python SDK of Google Cloud Vertex AI allowed an attacker without credentials or prior access to the victim's project to kidnap the burden of a model and execute code in Google's serving infrastructure. Palo Alto Networks Unit 42 baptized the technique as "Pickle in the Middle" and reported the problem to Google; the manufacturer has already patched the SDK, but the incidence leaves important lessons on design risks and unsafe practices in machine learning pipelines.

The technical root was simple and dangerous: when the SDK needed a temporary bucket to upload model artifacts and the user did not specify one, it generated a predictable name from the project ID and the region - for exampleproject-vertex-staging-region- and checked only if it existed, not if the bucket belonged to the user's project. Since the names of buckets are globally unique, an attacker with his own project could first create that bucket and wait for the victim to rise. The attacker then replaced the contents raised by a malicious artifact. Since many Python models are serialized with pickle or jobligb - formats that run code when deerializing -, when Vertex AI loaded that model the attacker's payload was run inside the serving container.

The operation was dependent on a time window (TOCTOU): Unit 42 measured an interval of approximately 2.5 seconds between the rise and reading by Vertex AI; in its concept test a Cloud Function replaced the object in 1.4 seconds and the payload stole an OAuth token from the container's metadata server, sending it to the attacker. This token, in the test environment, had more extensive permissions than the simply committed instance: it allowed access to other artifacts in the Google-managed tenant, including complete models, BigQuery metadata, access lists, logs and internal container image routes. In other words, the holding could result in remote code execution, model theft and lateral movement within the tenant.

The vector worked only if there were two common conditions: that the default buffer of staging did not exist in the region (usual situation in new projects) and that the developer had not explicitly established the parameterstaging _ buck. Unit 42 reported vulnerability on March 5, 2026; Google launched an initial arrangement (randomizing the name with uuid4) and completed the correction by adding a verification of the Bucket ownership in Model.upload () in the version 1.148.0 of the package.

The implications for ML and safety equipment are wide: beyond the loss of intellectual property (stolen or poisoned models), the technique highlights how design decisions in insecure customers and defaults can become climbing vectors without phishing or complex exploits. It also stresses the risk of unsafe serialization formats in multi-tenant environments and the need for policies that avoid the creation of predictable resources that can be exploited by a competitor or an external attacker.

Recommended immediate actions: update the SDK to the parcheed version with the app command (e.g.pip install --upgrade google-cloud-aiplatform > = 1.148.0) and, very important, always define explicitly staging _ buck like a Cloud Storage location you control. Check the version ofgoogle-cloud-aiplatformwherever it is run: notebooks, CI / CD, training pipelines and test environments, not just in production. If you suspect that there may be exposure before the patch, consider rotating affected service credentials and tokens and review the history of public or shared buckets objects.

In addition to patching, review your serialization practices: if possible, avoid sending models in formats that run code on load such as pickle / jobligb; prefer formats designed for safe deployment (SavedModel, ONNX or exports that do not execute code on loading). At the access control level, limit the permits associated with service agents and accounts, use Workload Identity and implement organizational policies that prevent the creation of resources with predictable names or that require the linking of buckets to specific projects.

For response and risk equipment, audit Cloud Storage and Vertex AI log for unusual operations in model loading windows, and review access to server metadata and tokens issued by managed services. This incident replaces on the table the need to treat the ML supply chain as a threat vector: from the client code to the devices that are deployed in production.

Read the technical analysis and notification of the original researcher on the Unit 42 website for details of PoC and operating times: Unit 42. Check the launch notes and SDK versions in the official repository to confirm that your environment is updated: python-aiplatform releases and the package page in PyPI: google-cloud-aiplatform on PyPI. Act today: patch and fix the staging bucket removes the known attack window; complement it with safe access controls and serialization practices significantly reduces the risk.