Google Cloud Vertex AI Flaw Could Have Let Attackers Hijack and Poison ML Models

A vulnerability in the Google Cloud Vertex AI Python SDK could have allowed attackers to hijack machine learning model uploads, replace them with poisoned versions, and run malicious code inside managed Vertex AI serving environments.

The issue affected google-cloud-aiplatform versions 1.139.0 and 1.140.0, according to Unit 42 researchers at Palo Alto Networks. Google has since fixed the flaw, with the permanent fix released in version 1.148.0 on April 15, 2026.

The attack did not require access to the victim’s Google Cloud project. It relied on predictable default Cloud Storage bucket names, missing bucket ownership checks, and the unsafe deserialization risk of Python pickle-based model files.

How the Vertex AI Model Hijacking Worked

Vertex AI is used by developers and data science teams to train, manage, tune, and deploy machine learning models. Google now presents many of these capabilities through its Gemini Enterprise Agent Platform, which includes model training and deployment features for enterprise AI projects.

The vulnerable SDK behavior appeared when a developer uploaded a model without explicitly setting a staging bucket. In that case, the SDK generated a default staging bucket name from the project ID and region.

The SDK checked whether that bucket name already existed, but it did not confirm that the bucket belonged to the victim’s project. An attacker who knew or guessed the victim’s project ID could create the expected bucket name first in a separate Google Cloud project.

Issue	What happened
Affected package	google-cloud-aiplatform
Affected versions	1.139.0 and 1.140.0
Attack method	Bucket squatting and model replacement
Required attacker access	A Google Cloud project and the victim project ID
Final risk	Model poisoning, credential theft, and remote code execution
Fixed version	google-cloud-aiplatform 1.148.0 or later

Researchers Called the Attack Pickle in the Middle

Unit 42 called the technique Pickle in the Middle because the attacker sits between the victim’s upload and Vertex AI’s model loading process. The attacker’s goal is to replace the legitimate model artifact before Google’s service agent reads it.

The attack window was short. Unit 42 said its tests showed about 2.5 seconds between the victim’s upload and the service agent reading the model. A cloud function triggered by the new object upload could react quickly enough to swap the file before deployment.

The final step relied on Python pickle deserialization. The official Python pickle documentation warns that pickle is not secure and that malicious pickle data can execute arbitrary code during unpickling.

1. The attacker predicts the victim’s default Vertex AI staging bucket name.
2. The attacker creates that bucket in a separate Google Cloud project.
3. The attacker allows the victim and Vertex AI service agent to read and write objects.
4. The victim uploads a model without specifying a staging bucket.
5. The SDK uploads the model artifacts to the attacker-controlled bucket.
6. A cloud function replaces the legitimate model file with a poisoned version.
7. Vertex AI later loads the model, triggering malicious code execution through deserialization.

What Attackers Could Access After Exploitation

The proof-of-concept attack showed that malicious code could run inside the Vertex AI serving container. Unit 42 said the payload queried the Google Compute Engine metadata server and exfiltrated service account credentials.

The stolen OAuth token belonged to a service account running in Google’s managed tenant project and carried broad cloud-platform scope. Researchers found that this token could access resources beyond the single model deployment.

The risk included model theft, BigQuery reconnaissance, and access to infrastructure details from Cloud Logging. That made the vulnerability more serious than a simple model upload bug because it crossed into the wider cloud environment used to serve models.

Potential attacker action	Impact
Steal service account tokens	Use cloud credentials from the managed serving environment
Read other model artifacts	Access models stored in the same tenant project
Enumerate BigQuery datasets	Map dataset names, table names, and access controls
Read Cloud Logging data	Collect internal infrastructure and deployment details
Poison deployed models	Run attacker-controlled code when the model is loaded

Google Fixed the SDK in Two Stages

Google accepted the report through its Vulnerability Reward Program and deployed fixes in two stages. The first fix, released in version 1.144.0 on March 31, 2026, added randomization to the default bucket naming routine.

The second fix arrived in google-cloud-aiplatform 1.148.0 on April 15, 2026. The release notes say the update added bucket ownership verification to prevent bucket squatting in Model.upload().

Developers using vulnerable versions should upgrade immediately. The latest GitHub release notes confirm that the bucket ownership check was added as a bug fix in version 1.148.0.

• Upgrade google-cloud-aiplatform to version 1.148.0 or later.
• Search build systems, notebooks, containers, and CI pipelines for pinned vulnerable versions.
• Set the staging_bucket parameter explicitly when uploading models.
• Use a Cloud Storage bucket that your organization owns and controls.
• Validate model artifacts before deployment.
• Avoid loading untrusted pickle or joblib model files.
• Review service account permissions used in model training and serving workflows.

Why Pickle-Based ML Models Create Extra Risk

Many Python machine learning workflows use pickle directly or through tools such as joblib. This makes model files more than passive data. If the model file comes from an untrusted source or changes before deployment, loading it can become a code execution event.

The pickle module documentation explicitly warns users never to unpickle data that could have come from an untrusted source or that could have been tampered with. That warning applies directly to ML model pipelines that move artifacts between storage, training, and serving systems.

For teams using Google Cloud machine learning tools, the lesson is to treat model artifacts like software supply chain assets. Model files should have ownership controls, integrity checks, restricted write paths, and deployment approvals.

AI Pipeline Security Now Includes Storage and SDKs

This case shows how AI security extends beyond prompts, model behavior, and training data. A small SDK design flaw in staging logic created a path for cross-project model hijacking.

The vulnerable path depended on normal developer behavior. A victim only needed to call Model.upload() without a custom staging bucket, which is a common pattern in development and automation workflows.

Google’s machine learning platform documentation describes a full lifecycle for building, training, and managing ML models at scale. That lifecycle now needs the same security controls that organizations already apply to software builds, container images, secrets, and production deployments.

What Developers Should Do Now

Developers should first confirm which version of google-cloud-aiplatform runs in notebooks, build images, deployment jobs, and production automation. Any environment using versions 1.139.0 or 1.140.0 should move to a fixed release.

Security teams should also check for model uploads that used default staging behavior in regions where the default bucket did not already exist. While Google fixed the SDK, older artifacts and logs may still help determine whether unexpected buckets or model changes appeared during the vulnerable window.

The Unit 42 research recommends upgrading to 1.148.0 or later and explicitly setting a Cloud Storage staging bucket for model uploads. Organizations using Google Cloud AI services should also review service account scopes and artifact integrity controls across the ML lifecycle.

FAQ