The vulnerability discovered in Google Cloud’s Vertex AI Python SDK demonstrates how a seemingly minor weakness in cloud resource handling can undermine the isolation between separate customer environments. Researchers from Palo Alto Networks Unit 42 found that vulnerable versions of the SDK could allow an attacker with no initial access to a victim’s Google Cloud project to hijack a machine-learning model upload, replace the model with a malicious version, and potentially execute code within the victim’s Vertex AI serving infrastructure. 

The issue arose from the way the SDK automatically created a default Google Cloud Storage staging bucket when a developer uploaded a model without specifying one. The bucket name was generated using a predictable combination of the customer’s project ID and deployment region. Because Cloud Storage bucket names are globally unique, an attacker who knew or guessed those details could create the expected bucket first in their own Google Cloud project, a technique known as bucket squatting. 

The SDK reportedly checked whether the predicted bucket already existed but failed to verify that it actually belonged to the customer’s project. Consequently, when the victim performed an otherwise routine model upload, the SDK could silently place the model files inside an attacker-controlled bucket. This is an important distinction: exploitation did not require the victim to approve a malicious login, install malware, or misconfigure IAM permissions. The developer could simply use the affected SDK’s default behaviour, trusting that a cloud library would verify ownership of the infrastructure it selected. An optimistic assumption, and therefore exactly the kind attackers enjoy finding. 

After receiving the legitimate model files, the attacker could replace them during the window between upload and deployment. When the victim later deployed the model, Vertex AI’s service infrastructure would retrieve the attacker-modified files from the compromised staging location. Researchers demonstrated that this could lead to remote code execution by inserting a malicious serialized Python object into the model. 

The attack relied partly on Python’s `pickle` serialization mechanism, which is commonly used directly or through libraries such as Joblib to save and load machine-learning models. Pickle files are capable of invoking executable Python behaviour when they are deserialized. Therefore, loading a pickle-based model from an untrusted or compromised location can execute attacker-controlled code before meaningful validation takes place. 

A successful attack could potentially allow the threat actor to steal model data, access credentials available to the serving environment, exfiltrate information, move laterally through connected cloud resources, poison AI outputs, or establish further persistence. The exact impact would depend on the permissions assigned to Vertex AI service identities and the systems accessible from the deployed model environment. 

The cross-tenant nature of the vulnerability makes it particularly significant. The attacker could prepare the malicious bucket entirely from a separate Google Cloud account and did not require prior compromise of the customer’s users, endpoints, or cloud credentials. The victim’s own trusted SDK and managed cloud workflow would then become part of the attack chain. This is precisely why cloud security cannot be reduced to protecting usernames and passwords. Sometimes the attacker does not steal the key; the software politely delivers the assets to the attacker’s storage account.

Unit 42 identified the issue in `google-cloud-aiplatform` SDK versions 1.139.0 and 1.140.0, which were the latest versions available during the researchers’ testing. Google addressed the issue in version 1.148.0, released on April 15, 2026, and organizations should move to the latest supported SDK release rather than treating 1.148.0 as a permanent stopping point. 

For customers using Vertex AI, the first priority should be to inventory every environment using the `google-cloud-aiplatform` Python package. This includes developer systems, notebooks, CI/CD pipelines, MLOps platforms, training jobs, automated deployment workflows, container images, and serverless functions. Dependency records and software bills of materials should be checked to identify vulnerable versions, including versions embedded inside older container images that may no longer appear in active development repositories.

Organizations should upgrade the SDK and rebuild affected containers and deployment artifacts. Merely updating a developer’s workstation may not address scheduled pipelines or production automation that continues to use an older pinned dependency. Security teams should also confirm that dependency-lock files, internal package mirrors, base images, and build templates reference a corrected release.

Customers should review the Cloud Storage buckets used for Vertex AI model staging and confirm that each bucket is owned by the correct project. Any automatically generated staging bucket whose ownership, IAM configuration, creation history, or project association cannot be verified should be treated as suspicious until investigated.

Organizations should explicitly define and provision staging buckets rather than relying unnecessarily on automatically generated defaults. These buckets should be created within approved customer projects, protected with uniform bucket-level access, restricted to required service identities, monitored through audit logging, and prevented from granting broad permissions such as access to all authenticated Google users.

Security teams should examine Cloud Audit Logs for unexpected model uploads, access to staging buckets from unfamiliar projects or identities, changes to object contents between upload and deployment, and unusual model deployment activity. They should also look for buckets matching predictable Vertex AI naming patterns that were created outside the expected project or before the organization began using Vertex AI in a particular region.

Model integrity must also become part of the deployment process. Organizations should calculate cryptographic hashes or apply digital signatures when models are produced and verify them immediately before deployment. A model should not be trusted merely because it is stored in a location that looks like the expected cloud bucket. Names are not ownership proofs, despite decades of computing repeatedly learning this lesson and then misplacing the notes.

Where pickle or Joblib formats are unavoidable, model files should only be loaded from strongly authenticated and integrity-verified sources. Safer serialization formats should be considered where technically possible, particularly for models exchanged between teams, environments, or external suppliers. Pickle-based files obtained from unknown or mutable locations should be treated similarly to executable code.

Customers should also apply least privilege to the Vertex AI service agent and any user-managed service accounts involved in model deployment. These identities should only be permitted to access the specific buckets, registries, secrets, networks, and APIs required for their function. Excessive cloud permissions can turn an isolated code-execution event into a broader compromise involving databases, storage repositories, credentials, or production workloads.

Network controls remain important even in managed AI platforms. Outbound communication from model-serving environments should be restricted wherever the architecture permits it. DNS monitoring, egress filtering, workload segmentation, cloud firewall policies, and anomaly detection can help identify a malicious model attempting to contact external infrastructure or exfiltrate information.

Customers should additionally monitor for unexpected processes, command execution, new network connections, unusual service-account token requests, changes to deployed models, and anomalous access to secrets or Cloud Storage resources following a model deployment. These indicators should be correlated across cloud audit logs, workload telemetry, identity systems, network controls, and security monitoring platforms.

The incident reinforces a broader lesson about AI security: the machine-learning lifecycle is now part of the software supply chain. Models, datasets, SDKs, notebooks, staging buckets, registries, pipelines, service accounts, and serving containers must all be treated as security-sensitive components. Protecting only the final AI endpoint leaves multiple earlier stages where attackers can substitute, poison, or redirect trusted artifacts.

For enterprises building or adopting AI systems, security controls must therefore extend from development through deployment and runtime. Dependencies should be continuously assessed, cloud resources should have verified ownership, models should have integrity protection, service identities should be tightly scoped, and data movement should be monitored. The Vertex AI flaw shows that an attacker may not need to break into the front door when a predictable bucket name and an unchecked assumption can redirect the entire deployment pipeline into their hands.

A flaw in the Google Cloud Vertex AI SDK for Python let an attacker with no access to a victim's project hijack the victim's machine learning model upload and run code inside Google's serving infrastructure. Palo Alto Networks Unit 42, which found and reported the bug through Google's bug bounty program, calls the technique "Pickle in the Middle" and said it saw no exploitation in the wild.

Source: Google Vertex AI SDK Flaw Let Attackers Hijack Model Uploads via Bucket Squatting via The Hacker News — published 16 Jun 2026.