Pickle in the Middle: Google Vertex AI SDK Flaw Gave Attackers Code Execution Inside Google's Cloud

A security flaw in the Google Cloud Vertex AI SDK for Python allowed an unauthenticated external attacker to hijack a victim's machine learning model upload and execute attacker-controlled code inside Google's cloud serving environment, Palo Alto Networks Unit 42 researchers disclosed in mid-2026.

What Happened

Unit 42 named the technique "Pickle in the Middle" — a nod to both the attack's man-in-the-middle staging mechanic and Python's `pickle` serialization format, which sits at the center of the exploit chain. Google patched the vulnerable `google-cloud-aiplatform` Python SDK after receiving a bug bounty report. No exploitation in the wild has been observed, and no CVE has yet been assigned at time of publication.

How the Attack Works

The mechanics are quiet. Ugly, but quiet.

Under specific SDK workflows, Vertex AI staged model artifacts through a Google Cloud Storage bucket whose name was predictable or could be claimed by an adversary in advance. Classic bucket squatting. An attacker who registered the bucket name before the victim's tooling attempted to write there would receive the victim's serialized model file on its way to deployment.

Python's `pickle` format then did the rest. Pickle executes arbitrary code at deserialization time — that behavior is documented and well-understood, and it is precisely why security teams have warned against using it across trust boundaries for years. Once a tampered pickle artifact lands in Vertex AI's prediction container, the container loads it faithfully. Whatever payload the attacker embedded runs inside Google's managed serving environment, under the victim's service identity.

The model server behaved exactly as designed. It loaded a pickle. The design was the problem.

No IAM Foothold Required

This detail demands attention. The attack required zero Identity and Access Management (IAM) permissions inside the target Google Cloud project. The attacker needed only two things: knowledge of the predictable bucket name, and the speed to claim it first. That is a remarkably low bar for gaining code execution adjacent to a production ML inference endpoint.

Unit 42 frames this as a supply-chain-adjacent issue rather than a flaw in the Vertex AI platform itself. That framing matters for detection engineers. The trust boundary that broke existed between the developer's local machine and the cloud storage layer — not between the model server and the outside world. By the time Vertex AI touched the artifact, it was already compromised.

Why Pickle Keeps Showing Up

Pickle-based payload delivery is not new. It has appeared in commodity Python supply-chain attacks for years, typically targeting open-source model repositories and ML pipelines where researchers download and load pre-trained weights without verifying their integrity. The Vertex AI case extends that pattern into a managed cloud environment, which raises the stakes considerably.

The Verizon 2024 Data Breach Investigations Report found that software supply chain attacks grew 68% year-over-year, with third-party software components and build pipeline tampering accounting for a growing share of that figure. ML pipelines, which frequently ingest external artifacts and rely heavily on Python serialization, represent an underdefended segment of that attack surface.

"The trust model most ML teams operate under assumes the artifact they're loading is the artifact they wrote," a Unit 42 researcher noted in the original disclosure. "Bucket squatting breaks that assumption silently."

The Broader Threat Context

No threat intelligence cluster has been publicly tied to this specific technique yet. Treat capability and intent separately. The capability is real and documented. Who would use it, and against whom, remains unproven.

That said, ML pipeline tampering has attracted research interest from several sophisticated threat actors. Gaining code execution adjacent to a production inference endpoint would provide access to training data, model weights, downstream API keys stored in environment variables, and potentially lateral movement paths through the service account's permissions. For an adversary targeting an organization's AI assets, that is a meaningful prize.

Which Controls Failed

The root cause here is a failure of supply-chain integrity hygiene at the storage layer. The SDK's auto-generated bucket naming gave attackers a predictable target. No integrity verification — no hash check, no signing, no attestation — stood between the storage write and the container load. The `pickle` format's inherent code-execution behavior turned a storage manipulation into full remote code execution.

This is also a story about developer trust assumptions. Engineers who use managed SDK abstractions reasonably expect the SDK to handle staging securely. When an SDK automatically provisions infrastructure with guessable names and no ownership validation, the developer has no visibility into the risk they are accepting. Security awareness alone cannot fix a SDK design flaw — but awareness of *why* pickle is dangerous, and *why* storage bucket names matter, shapes the engineering decisions that prevent these situations. Teams that understand serialization risks are more likely to question auto-generated configurations and push for safer alternatives. Organizations running security-awareness programs that include developer-focused content, like the modules available at Train2Secure, give their engineers the context to raise those questions before a bug bounty report does.

What Defenders Should Do Now

The remediation list is short but concrete.

Upgrade immediately. Update the `google-cloud-aiplatform` Python package to the current release. Audit every CI/CD job pinned to an older version — automated pipelines are the most likely path to running vulnerable SDK code at scale without human review.

Pre-create and lock staging buckets. Do not let tooling auto-generate bucket names. Create buckets with explicit, organization-controlled names before onboarding any ML workflow, and apply IAM policies that restrict writers to known service accounts.

Treat pickle artifacts as executable code. Any pickle file crossing a trust boundary — from developer machine to cloud storage, from external repository to local inference — should be treated with the same suspicion as a binary executable. Where Vertex AI supports safer serialization formats, use them. Where it does not, add integrity verification at the storage layer.

Add logging and alerting for unexpected bucket writers. Cloud Storage audit logs can surface unexpected principals writing to model-staging buckets. If a principal outside your known CI/CD service accounts writes to a staging bucket, that is worth an alert.

Watch for the CVE. A formal CVE assignment for this flaw, when it issues, will specify the exact affected version range. Subscribe to the NVD feed for `google-cloud-aiplatform` and validate your environment against the published range.

Organizations building ML infrastructure on Google Cloud should review their security posture and compliance standards and consider whether their developer training covers supply-chain and serialization risks specifically. The gap between "we patched the SDK" and "we understand why this was dangerous" is where the next incident starts.

For teams looking to assess their training coverage without a procurement process, a free trial is the fastest way to find out what your developers do and do not know about secure-by-default cloud development.