Bucket Squatting — When Google’s Defaults Become Your Breach
Two bucket-squatting flaws in Vertex AI. Same year. Same vendor. Same problem.
Google patched the latest one. Cool.
But here’s what bothers me: 2.5 seconds.
That’s the window between your model upload and Vertex AI reading it. Attackers measured it. Built a Cloud Function that replaces your model in 1.4 seconds.
They beat Google’s own infrastructure by a full second.
No credentials. No phishing. No breach of your project.
Just a predictable bucket name and a developer who trusted the default.
Every step in the attack chain is authorized. Your SDK uploads to the attacker’s bucket. Vertex AI loads the swapped model. The attacker’s code runs inside Google’s serving container. Your WAF sees nothing. Your IAM says “working as designed.”
How It Works — No Magic, Just Lazy Defaults
The Google Cloud Vertex AI SDK for Python needs a staging bucket for model uploads. If you don’t set one, the SDK generates a predictable name: project-vertex-staging-region.
Bucket names are globally unique. Anyone can create that bucket in their own project.
If an attacker creates it first, your SDK uploads your model to their bucket. They replace it with a malicious pickle file. Vertex AI loads it. Attacker code runs inside Google’s serving container.
Steals an OAuth token from the metadata server. Access to other models. BigQuery metadata. GKE clusters. Internal container paths.
All because you left a parameter unset.
Palo Alto Networks Unit 42 found and reported the flaw through Google’s bug bounty program. They call the technique “Pickle in the Middle.” Saw no exploitation in the wild. But the window was wide open.
The “Pickle in the Middle” — Why This Is Worse Than It Sounds
Unit 42 calls it “Pickle in the Middle.” Fitting.
Pickle files can run code when loaded. That’s not a bug. That’s how pickle works. The attack relies on Python’s standard serialization format executing arbitrary code.
Many ML models are saved with pickle or joblib. Standard practice. No one thinks twice.
The attacker’s payload steals the OAuth token from the serving container’s metadata server. In Unit 42’s test environment, that token wasn’t limited to the compromised deployment. It could access other model artifacts in the same Google-managed tenant project.
- Full TensorFlow models with trained weights
- BigQuery metadata
- Access lists
- Tenant logs
- GKE cluster names
- Internal container image paths
One predictable bucket name. One model swap. Full tenant access.
The Pattern — Two Flaws, Same Vendor, Same Year
This isn’t isolated. In February, Google patched CVE-2026-2473 — a separate bucket-squatting flaw in Vertex AI Experiments. Same pattern. Predictable bucket names. Cross-tenant execution. Model theft. Poisoning.
Two flaws. Same vendor. Same year. Same root cause.
That’s not a coincidence. That’s a systemic failure.
AI platforms are building fast. Security is an afterthought. Defaults prioritize convenience over protection.
And developers are paying the price.
What This Means for You
If you’re using Vertex AI, your upload pipeline is a potential entry point. Not because you made a mistake. Because Google made assumptions you didn’t know about.
The attack worked only under specific conditions: the victim’s default staging bucket didn’t already exist in that region, and the victim left the staging_bucket parameter unset. The first is common for a new project in Vertex AI in a region.
The second depends on the developer relying on the SDK’s default rather than naming their own bucket.
What You Should Check Today
- ✅ Update the SDK: Version 1.148.0 or later has ownership verification. Don’t skip this.
- ✅ Set an explicit staging bucket: Never rely on the SDK’s default. Name your own bucket. Verify you own it.
- ✅ Audit your upload pipelines: Check notebooks, CI jobs, training pipelines. The flawed logic lives in the client SDK. Not just production services.
- ✅ Review tenant permissions: If an attacker can access your tenant project, what can they see? What can they steal?
- ✅ Pentest your AI infrastructure: Defaults fail. Assumptions fail. Test them before an attacker does.
The Bottom Line
Google patched it. Update to 1.148.0.
But the real fix isn’t a version number. It’s a mindset.
Stop trusting defaults. Set your own buckets. Verify ownership. Assume the SDK is lazy. Assume the platform is insecure.
Because the next flaw isn’t patched yet. And it won’t be a predictable bucket name. It’ll be something else you assumed was safe.
Same vendor. Same year. Two flaws. Same pattern.
AI platforms build fast. Security lags. You’re the one who pays.
Bucket squatting works because developers trust defaults. AI platforms reward convenience. Attackers exploit the gap.
A pentest finds these blind spots. A retainer keeps finding new ones.
Your AI infrastructure is only as secure as its weakest default.
Full AI Agent Pentest: €3,000 — MCP injection testing, data boundary audit, full red team.
Security Retainer: €1,500/month — continuous validation.
Free 15-min consultation. No Calendly. Just honest answers about what your AI is really trusting.
Leave a Reply