'Pickle in the Middle': Vertex AI SDK Bug Let Outsiders Hijack Model Uploads

Key points

• A flaw in the Vertex AI SDK for Python let an unauthenticated outsider intercept a model upload and run attacker-controlled code inside Google's serving infrastructure.
• The attack, named "Pickle in the Middle" by Palo Alto Networks Unit 42, exploited predictable Cloud Storage bucket names to stage a tampered model artifact.
• Google patched the SDK after a bug bounty report; Unit 42 has not observed exploitation in the wild.
• The compromise required no IAM foothold in the target project, only control of the bucket name and the victim using the vulnerable SDK path.
• No CVE has been assigned yet; watch for one to confirm the exact affected version range.

How does the attack actually work?

The Vertex AI SDK, under certain workflows, staged model artifacts through a Cloud Storage bucket whose name an attacker could predict or claim first. Classic bucket squatting. Once the adversary owned the bucket the victim's tooling expected to write to, the victim's pickled model file landed in attacker-controlled storage on the way to deployment.

Python's pickle format executes code on deserialization, so a tampered artifact loaded by Vertex AI's prediction container runs whatever the attacker embedded, inside Google's managed serving environment, under the victim's service identity. The model server behaved exactly as designed. It loaded a pickle.

Why does this sit outside the usual platform-vulnerability bucket?

Unit 42 frames this as a supply-chain-adjacent issue rather than a Vertex AI platform flaw, and the distinction matters for detection engineering. The trust boundary that broke was between the developer's machine and the cloud storage layer, not the model server. Defenders scanning for platform misconfigurations won't catch it there.

This is one of two pickle deserialization stories we've covered since June, and both expose the same structural problem: pickle artifacts crossing trust boundaries are executable code, yet tooling still treats them as inert files.

Should you worry about ML pipeline targeting?

There's no public CTI cluster tied to this technique yet, and no vendor has attributed activity to a named actor. Treat capability and intent separately. The capability is real and well documented by Unit 42. Who would burn it, and against whom, is unproven.

The pattern fits a known interest area for several adversary sets, and pickle-based payload delivery has appeared in commodity Python supply-chain attacks for years. Hijacking a Vertex AI upload would give an operator code execution adjacent to production inference and access to downstream model endpoints. Whether nation-state groups have operationalized anything resembling this is, at medium confidence, an open question.

What should defenders do now?

• Upgrade the google-cloud-aiplatform Python SDK to the current release and audit any CI/CD jobs pinned to older versions.
• Pre-create and lock down staging buckets with explicit names rather than letting tooling auto-generate them.
• Treat any pickle artifact crossing a trust boundary as executable code; prefer safer serialization formats where Vertex AI supports them.
• Log and alert on unexpected writers to model-staging buckets.

A CVE assignment, if one issues, will confirm the exact affected version range and is worth watching for.

My read: The scarier detail isn't the bucket squatting, which is fixable with a naming policy. It's that the model server did nothing wrong. The attack lives entirely in the handoff between developer tooling and storage, which means your platform security controls likely miss it entirely. Detection engineering teams need to own this one, not cloud security.