Palo Alto Networks Unit 42 publicly disclosed CVE-2026-2473, a vulnerability in the Google Cloud Vertex AI Python SDK that allowed an attacker with zero access to a victim’s Google Cloud project to execute arbitrary code within the victim’s Vertex AI model-serving environment. Unit 42 named the technique “Pickle in the Middle” combined with “bucket squatting” — an attack chain requiring only knowledge of the target’s publicly discoverable GCP project ID.
The Predictable Bucket Name That Gave Attackers Cross-Tenant Code Execution
The root cause of CVE-2026-2473 is the SDK’s bucket name generation logic. When a Vertex AI SDK user did not explicitly specify a Cloud Storage bucket during a model upload, the SDK generated a default bucket name derived entirely from publicly discoverable information: the user’s GCP project ID and region. For example, a project named “acme-prod” in the us-central1 region would generate the bucket name “acme-prod-vertex-staging-us-central1.”
The SDK verified only that a bucket with that name existed — not that the caller owned it. An attacker who knew the victim’s project ID could preemptively create a Cloud Storage bucket under that same predictable name within their own GCP project, before the victim had ever uploaded a model. When the victim subsequently ran model upload code without specifying an explicit bucket, the SDK placed the model artifact into the attacker’s bucket rather than the victim’s infrastructure.
How the Squatted Bucket Becomes a Code Execution Channel via Pickle Deserialization
With the model artifact now residing in the attacker-controlled bucket, the second phase of the attack exploits how Vertex AI’s serving runtime processes the uploaded artifact. The runtime fetches and deserializes the model using Python’s Pickle format — a deserialization mechanism that can encode arbitrary executable object graphs, not just data structures.
A crafted malicious “model” artifact placed in the squatted bucket executes attacker-controlled code inside the victim’s Vertex AI serving environment when the runtime deserializes it. No further interaction from the victim is required: the victim’s own model serving pipeline, executing as expected from the victim’s perspective, delivers and runs the attacker’s payload within the victim’s GCP tenant.
The victim’s GCP project ID — the only piece of information the attacker needed to initiate the attack — is frequently publicly visible. GCP project IDs appear in GitHub repositories, Terraform configuration files, CI/CD pipeline logs, and developer documentation. An attacker scanning public code repositories for GCP project IDs would have the primary input for targeting Vertex AI SDK users at scale.
Google’s Two-Phase Fix: UUID4 Randomization Then Ownership Verification
Unit 42 reported the flaw to Google on March 5. Google issued an initial fix in google-cloud-aiplatform v1.144.0 on March 31 by adding a random UUID4 component to the generated bucket name, making the name unpredictable and preventing pre-squatting. Google completed the full remediation in v1.148.0 on April 15 by adding bucket ownership verification — so that even if an attacker could predict or discover a bucket name, the SDK would confirm the bucket belongs to the caller’s project before placing artifacts in it.
No exploitation in the wild was confirmed by Unit 42. The June 16—17 public disclosure follows the coordinated private disclosure and patch timeline.
Cross-Tenant Cloud Attacks and the Trust Assumptions They Break
Cross-tenant attacks — where one cloud customer can compromise another customer’s serving infrastructure — are particularly significant because cloud tenancy is a foundational security boundary. Organizations building production systems on GCP operate on the assumption that their project’s infrastructure is inaccessible to other GCP customers. CVE-2026-2473 violated that boundary without requiring any foothold in the victim’s account.
The attack required no authentication to the victim’s GCP project, no knowledge of credentials or access keys, and no interaction with the victim beyond their running a standard SDK operation. The attack surface was the SDK’s own default behavior combined with Pickle’s ability to encode executable code — both of which are features of the system operating as designed, until the SDK’s bucket validation logic failed to enforce ownership.
Organizations using the google-cloud-aiplatform SDK should verify they have upgraded to v1.148.0 or later. Users on versions prior to v1.148.0 who performed model uploads without explicitly specifying a Cloud Storage bucket should also audit whether any unexpected buckets matching their project’s default naming pattern exist in other GCP projects — a step that would identify whether pre-squatting attempts were made against their project IDs before the patch was applied.
