On April 15, 2026, Google released version 1.148.0 of the google-cloud-aiplatform SDK, patching a vulnerability discovered by Palo Alto Networks' Unit 42 team that allowed an attacker to achieve remote code execution in a victim's Vertex AI serving infrastructure without any access to the victim's cloud project. The linchpin is a deterministic naming pattern for temporary staging buckets, combined with the SDK client's lack of an ownership check. The attack works entirely cross-tenant: the attacker operates from their own Google Cloud project, with any billing account.
- Vulnerable code in
gcs_utils.pygenerates the staging bucket name by concatenating the project ID, the fixed string "vertex-staging", and the location, making the name predictable and squattable - The
staging_bucket.exists()check verifies only the bucket's existence, not ownership by the calling project: if a bucket with that name exists in another project, the SDK silently uploads data to it - The attacker has roughly 2.5 seconds to swap the legitimate model with a malicious pickle payload before it is loaded into the serving container
- Execution occurs in the context of Vertex AI's Per-Product, Per-Project Service Account (P4SA), with potential lateral movement in the victim's cloud environment
The Mechanism: When the Bucket Name Becomes an Attack Vector
The vulnerability resides in the stage_local_data_in_gcs() function in the gcs_utils.py module, at line 6: staging_bucket_name=project+"-vertex-staging-"+location. This line, present in SDK versions 1.139.0 and 1.140.0, implements a rigid, deterministic naming convention for the temporary staging buckets used during ML model uploads.
The problem emerges from the interaction between this convention and Google Cloud Storage properties. Bucket names must be globally unique across the entire GCS infrastructure. An attacker who knows the victim's project ID — information often publicly discoverable in repositories, technical documentation, or service URLs — can calculate the staging bucket name for a specific region. If the victim has never used Vertex AI in that region, the bucket does not exist. The attacker creates it in their own project. When the victim subsequently invokes the model upload, the if not staging_bucket.exists() check returns True: the bucket exists, but in the attacker's project, not the victim's.
The code proceeds with the upload without any further ownership verification. As Unit 42 states: "If the bucket exists, even in a completely different project, the SDK proceeds to upload model artifacts to it without any further verification."
"By exploiting this flaw in vulnerable versions of the SDK, an attacker can achieve remote code execution (RCE) within a target's Vertex AI serving infrastructure, with zero initial access to the victim's project." — Unit 42, Palo Alto Networks
The 2.5-Second Race Condition: Window for Model Poisoning
Once the legitimate model has been uploaded to the squatted bucket, the attacker must act quickly. Unit 42 researchers experimentally measured a time window of approximately 2.5 seconds to replace the model file with a malicious payload before the Vertex AI service pulls it and loads it into the serving container. As the researchers report: "Our tests show that this window is approximately 2.5 seconds, requiring near-real-time attacker operation."
The payload exploits pickle deserialization — or equivalently joblib — at the moment the model is loaded. Python's pickle executes the __reduce__ method of deserialized objects, allowing arbitrary code execution. The malicious model, ostensibly a standard ML model file, contains a pickle class with a modified __reduce__ to execute commands in the serving container's context.
Execution occurs with the credentials of Vertex AI's Per-Product, Per-Project Service Account (P4SA), a Google-managed service account with significant privileges within the victim's project. This opens possibilities for lateral movement in the cloud environment, though the brief does not specify precise techniques or scopes for this subsequent phase.
Why It Matters
The dossier does not confirm that the vulnerability was exploited in the wild before the fix was released. It is unknown whether Google actively notified users of potentially exposed projects, nor is it documented whether the fix in version 1.148.0 is limited to an ownership check or includes additional mitigations such as bucket name randomization.
The brief does not specify whether the project ID is the sole informational requirement for the attack or if additional parameters — such as the exact deployment region — are needed to calculate the target bucket name. The exact date of initial disclosure to Google and the duration of the interval between reporting and patch release are also not independently verifiable.
What makes this vulnerability significant in the cloud security landscape is the invisible nature of the implicit staging infrastructure. Developers using Vertex AI through the client SDK are not necessarily aware of the existence of automatically generated temporary buckets, nor that the names of these buckets are derivable from public information. The implicit trust in the client SDK as the guardian of multi-tenant isolation proves to be a systemic point of fragility here.
The Evolution of Cloud Squatting: From Forgotten Domains to Predicted Buckets
Cloud squatting — the practice of occupying cloud resources with predictable names before the legitimate owner needs them — has so far manifested primarily as the acquisition of expired domain names or abandoned S3 buckets. This vulnerability represents a qualitative mutation: it no longer involves resources forgotten by the user, but resources that the managed service will automatically generate in the future, with names perfectly calculable in advance.
Unit 42's angle highlights an architectural tension in managed AI services: the convenience of SDK abstraction requires the client to handle infrastructural details on the user's behalf, but this opacity also eliminates the visibility needed to assess security boundaries. The project ID, an element normally considered public and non-sensitive, becomes a critical identifier for targeting in this scenario.
According to the researchers: "The root enabler of this attack is a predictable default bucket name, combined with a missing ownership check in the SDK's staging logic." The combination of deterministic naming and implicit trust in the client creates a cross-tenant boundary that is violable without any prior compromise of the victim's account.
What to Do Now
The actions documented in the dossier are limited to the following:
- Verify the installed version of the
google-cloud-aiplatformSDK: versions 1.139.0 and 1.140.0 are vulnerable - Upgrade to version 1.148.0 or later, released on April 15, 2026 with the fix
- Determine whether the organization's project ID is publicly exposed in repositories, documentation, or accessible URLs
- Check whether buckets matching the pattern
{project-id}-vertex-staging-{location}have been created in projects not belonging to the organization
The brief does not document additional specific remediation measures or verification procedures for deployments already performed with vulnerable SDK versions.
Questions and Answers
Does the attack work with any version of the Vertex AI SDK?
No. Only versions 1.139.0 and 1.140.0 have been confirmed as vulnerable by Unit 42. Version 1.148.0, released on April 15, 2026, contains the fix.
Does the attacker need access to the victim's console or credentials?
No. The attack is fully cross-tenant. The attacker operates from their own Google Cloud project with any billing account. The sole documented requirement is knowledge of the victim's project ID.
Does the 2.5-second window make the attack impractical?
The researchers describe it as "near-real-time," indicating it requires attacker operation in immediate proximity to the victim's upload. It is not documented whether automation techniques could make it systematically exploitable.
Sources
Information is based on the cited source and current as of publication.