> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE
- URL: https://f4n6.co.uk/security-feed/pickle-in-the-middle-hijacking-vertex-ai-model-uploads-for-cross-tenant-rce/
- Published: 2026-06-16T11:21:47.000Z
- Updated: 2026-06-16T11:21:47.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 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

| Article                                                                              | Trigger (fact in this item)                                                                                                       | Practical impact                                                                                                                                                               |
| ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 28 — ICT third-party risk — general principles                             | Vertex AI is an ICT third-party service provided by Google Cloud; the vulnerable SDK is the integration point.                    | Firms must ensure third-party ICT risk management covers the SDK supply chain and that contractual / vendor arrangements with Google reflect timely vulnerability remediation. |
| DORA Art. 29 — Preliminary assessment of ICT concentration risk                      | Vertex AI usage for production ML model serving may constitute a concentration point if multiple critical workloads depend on it. | Firms should reassess concentration risk in light of this vulnerability and consider whether contingency / multi-provider strategies are warranted.                            |
| DORA Art. 30 — Key contractual provisions with ICT third-party providers             | Vendor (Google) has issued a fix; contractual provisions on patching and notification obligations are engaged.                    | Confirm with Google that remediation timelines align with DORA expectations and that contractual notification clauses are honoured.                                            |
| DORA Art. 24 — Digital operational resilience testing — general requirements         | The vulnerability affects production AI serving infrastructure; testing programmes must cover SDK dependencies.                   | Include SDK version verification and model-upload pipeline testing in resilience testing scope.                                                                                |
| NIS2 Art. 21(2)(d) — Supply chain security measures                                  | The vulnerability resides in a third-party SDK component of the AI/ML supply chain.                                               | In-scope entities must apply supply-chain security measures covering SDK provenance, version pinning and integrity verification.                                               |
| DORA Art. 17 / Art. 18 / Art. 19 — Incident management, classification and reporting | A successful exploitation produces an ICT-related incident (RCE in serving infrastructure) potentially classifiable as major.     | Pre-establish classification criteria and reporting playbooks for AI/ML pipeline compromises; ensure reporting timelines can be met if exploitation is confirmed.              |
| UK NIS 2018 — OES/RDSP duties                                                        | OES/RDSP entities running Vertex AI workloads have duties regarding the security of their network and information systems.        | Confirm SDK version status and apply the same upgrade and audit steps; document any suspected compromise under existing incident-handling duties.                              |

## 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.

| Type   | Value | Confidence | Source |
| ------ | ----- | ---------- | ------ |
| (none) | —     | —          | —      |

```iocs
(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.

```yara
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)
}

```

```yaml
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 →](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*