Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE

1. Executive summary

Unit 42 has disclosed a vulnerability in the Google Cloud Vertex AI Python SDK (google-cloud-aiplatform) that allows an attacker operating entirely from their own Google Cloud project to achieve remote code execution (RCE) inside a victim's Vertex AI serving infrastructure — with zero prior access to the victim's project. The flaw stems from a predictable default staging-bucket naming convention combined with a missing ownership check in the SDK's upload logic, enabling "bucket squatting" followed by pickle-deserialization of a poisoned model artifact. Affected SDK versions are 1.139.0 and 1.140.0; Google fixed the issue in v1.148.0 (released 15 April 2026). EMEA financial-services firms running ML/AI workloads on Vertex AI — particularly those uploading models without specifying a custom staging bucket — should treat this as a supply-chain risk requiring immediate SDK upgrade and audit of historical model uploads.

2. Regulatory framing

3. Technical analysis & attack chain

Attack chain (confirmed steps)

1. Reconnaissance (passive). Attacker identifies or guesses the victim's Google Cloud project ID and the region in which Vertex AI model uploads will occur. The default staging bucket name is constructed deterministically from these two values.
2. Bucket squatting. Attacker preemptively creates a Google Cloud Storage (GCS) bucket in their own Google Cloud project using the predicted name. Because GCS bucket names are globally unique, the attacker now owns the name.
3. Victim uploads a model. Victim runs the vulnerable SDK (v1.139.0 or v1.140.0) and uploads a model to the Vertex AI Model Registry without specifying a custom staging bucket. The SDK silently stages the model artifacts to the attacker-controlled bucket (no ownership check is performed).
4. Poisoning. Within a narrow window before the victim deploys the model, the attacker replaces the legitimate model artifact in the bucket with a malicious one. The malicious artifact leverages Python's built-in pickle module deserialization to deliver a payload.
5. Deployment and RCE. Victim deploys the (now-poisoned) model to a Vertex AI endpoint. Google's internal infrastructure — specifically a Per-Product, Per-Project Service Account (P4SA) — loads the artifact into a serving container, triggering pickle deserialization and arbitrary code execution inside the serving infrastructure.
6. Post-exploitation. From the serving container the attacker can perform data exfiltration, lateral movement and further compromise of the victim's cloud environment.

Technical specifics

• Vulnerable component: google-cloud-aiplatform (Vertex AI SDK for Python).
• Affected versions: 1.139.0 and 1.140.0 (the latter was the latest at the time of Unit 42's testing).
• Fixed version: v1.148.0, released 15 April 2026.
• Root cause: Predictable default staging-bucket name (derived from project ID + region) plus missing ownership check in the SDK's staging logic. When no custom staging bucket is supplied, the SDK silently uploads to the attacker-owned bucket.
• Attack primitive: GCS bucket squatting (global namespace collision).
• Code-execution primitive: Python pickle deserialization of attacker-supplied model artifact loaded by the P4SA into a serving container.
• Initial access requirement: None in the victim's project — the attack is fully cross-tenant from the attacker's own GCP project.
• Blast radius: Any Vertex AI serving endpoint that ingests a model uploaded via the vulnerable SDK without a custom staging bucket. Successful exploitation yields RCE in the serving infrastructure, with downstream potential for data exfiltration and lateral movement within the victim's cloud environment.

Caveats and unconfirmed points

• Unit 42 has not (in the supplied material) published a CVE identifier, CWE classification, or CVSS score for this issue. Severity is therefore inferred from impact (cross-tenant RCE in serving infrastructure) rather than from a scored assessment.
• No MITRE threat-actor attribution is provided. Treat any "APT-style" framing as unconfirmed.
• The exact deterministic bucket-naming formula (e.g., whether it incorporates a fixed prefix, the project number, or the region string) is not reproduced in the supplied excerpt; defenders should consult the full Unit 42 write-up before relying on a specific pattern for detection logic.

4. Mitigation & containment

P1 — within 24 hours

• Upgrade the SDK. Pin google-cloud-aiplatform to v1.148.0 or later across all development, CI/CD and production environments. Verify with: pip show google-cloud-aiplatform | grep Version
• Audit historical uploads. Identify any model uploads performed with v1.139.0 / v1.140.0 (or any unfixed version) where a custom staging bucket was not specified. Treat these as potentially compromised pending review.
• Inventory Vertex AI usage. Enumerate projects, regions and Model Registry entries that rely on Vertex AI serving endpoints.

P2 — within 72 hours

• Mandate custom staging buckets. Update upload pipelines to always pass an explicit staging_bucket= argument pointing to a bucket in the customer's own project that the customer controls. This eliminates the bucket-squatting primitive regardless of SDK version.
• Enable uniform bucket-level access and IAM-only authentication on all staging buckets; disable legacy ACLs.
• Restrict P4SA permissions to the minimum required for serving, and review Cloud Audit Logs for anomalous storage.objects.get / storage.objects.create activity against staging buckets during the vulnerability window.
• Review Cloud Logging for Vertex AI / Model Registry events between the date v1.139.0 was first deployed in your environment and the upgrade date; flag any model uploads where the destination bucket was not under your project.

P3 — within 7 days

• Add SDK version verification to CI/CD gates; fail builds that resolve to vulnerable versions.
• Add integrity checks (e.g., hash pinning or signed model artifacts) for model uploads so that substitution at the bucket layer is detectable.
• Tabletop exercise the scenario: assume a model was poisoned; rehearse detection, rollback to a known-good artifact, and customer/regulator notification under DORA Art. 17–19.
• Vendor engagement. Confirm with Google that contractual notification obligations under DORA Art. 30 have been satisfied and document the response.

5. Indicators of compromise

No specific indicators (hashes, domains, IPs, file names) are provided in the supplied source material. The vulnerability is a logic flaw rather than a discrete piece of malware, and the attacker's staging bucket is created in their own project — meaning it is not directly observable as an IOC in the victim's environment.

(no indicators available in the source material)

6. Detection

The supplied sources do not contain discrete hashes, command-line strings, mutex names or registry keys. The detection content below is constructed from the artefacts that are named in the source (Python pickle deserialization of model artifacts, and the Vertex AI staging-bucket naming pattern) and is intended as a starting point for defenders to tune against their own telemetry.

rule AT_VertexAI_PickleInTheMiddle_ModelArtifact
{
    meta
        author      = "Adverse Trace"
        date        = "2026-06-16"
        description = "Suspicious pickle deserialization patterns in Python model artifacts staged to Vertex AI"
        reference   = "https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/"

    strings:
        $pickle_load   = "pickle.load"
        $pickle_loads  = "pickle.loads"
        $cloudpickle   = "cloudpickle"
        $builtin_imp   = "__builtin__"
        $os_system     = "os.system"
        $subprocess    = "subprocess.Popen"
        $vertex_p4sa   = "service-@gcp-sa-aiplatform"

    condition:
        any of ($pickle_load, $pickle_loads, $cloudpickle) and
        any of ($builtin_imp, $os_system, $subprocess, $vertex_p4sa)
}

title: Vertex AI Model Upload to Non-Customer GCS Bucket
id: AT-2026-06-16-105-1
status: experimental
description: |
  Detects Vertex AI model uploads where the staging bucket is not under the
  customer's own GCP project, consistent with the "Pickle in the Middle"
  bucket-squatting technique.
author: Adverse Trace
date: 2026-06-16
reference: https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/
logsource:
  product: gcp
  service: audit
detection:
  selection:
    event_name:

      - "storage.objects.create"
      - "aiplatform.googleapis.com.UploadModelArtifact"
  filter_own_project:
    resource_name|contains: "/projects/<CUSTOMER_PROJECT>/"
  condition: selection and not filter_own_project
falsepositives:

  - Multi-project setups where Vertex AI workloads legitimately write to a shared bucket outside the customer's project; tune by project ID.
level: high

7. Sources

• Palo Alto Networks Unit 42 — Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE — https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/ — 16 June 2026.

8. Adverse Trace position

This is a high-impact supply-chain vulnerability: cross-tenant RCE in AI serving infrastructure with no prior access required, exploiting a globally unique namespace (GCS bucket names) and a deserialization sink (Python pickle). No CVSS score, CVE or CWE has been published in the source material, so severity is inferred from impact rather than scored; treat as High pending formal scoring. EMEA financial-services clients using Vertex AI for production model serving should prioritise the SDK upgrade to v1.148.0+, mandate custom staging buckets, and audit historical uploads performed on vulnerable versions. Adverse Trace will monitor for a CVE assignment, any in-the-wild exploitation reports, and Google's formal security advisory text, and will update this advisory accordingly. Clients requiring incident-response assistance should engage the Unit 42 IR team via the contact path in the source article.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.