{"slug": "cve-2026-2473-google-vertex-ai-sdk-let-attackers-run-your-code", "title": "CVE-2026-2473: Google Vertex AI SDK Let Attackers Run Your Code", "summary": "A vulnerability in Google Cloud Vertex AI Python SDK, tracked as CVE-2026-2473, allowed attackers to execute arbitrary code inside Google's AI infrastructure by squatting on predictable staging bucket names. Researchers at Palo Alto Networks Unit 42 demonstrated the attack, which required only a free Google Cloud account and the target's project ID. Google patched the flaw in versions 1.144.0 and 1.148.0.", "body_md": "A flaw in the Google Cloud Vertex AI Python SDK let attackers execute arbitrary code inside Google’s AI serving infrastructure — without ever accessing the victim’s GCP project. Researchers at Palo Alto Networks Unit 42, who named it “Pickle in the Middle,” disclosed the vulnerability in June 2026 under **CVE-2026-2473**. The attack required nothing more than a free Google Cloud account and knowledge of the target’s project ID — the kind of detail that’s often public. If you use the `google-cloud-aiplatform`\n\npackage and haven’t upgraded to v1.148.0 or later, read this.\n\n## The Bug: The SDK Generated Bucket Names It Couldn’t Verify\n\nWhen you call `Model.upload()`\n\nwithout specifying a staging bucket, the Vertex AI SDK automatically creates one. The naming pattern was deterministic: `{project-id}-vertex-staging-{region}`\n\n. The SDK checked whether that bucket existed in Google Cloud Storage — but it never checked whether the bucket *belonged to your project*.\n\nThis is where bucket squatting enters. Google Cloud Storage bucket names are globally unique across all GCP projects. Any GCP user can create any available bucket name in their own project. An attacker who knew a victim’s project ID — often embedded in GitHub repos, API docs, or GCS URLs — could pre-create the victim’s expected staging bucket in the attacker’s own account. When the victim later ran `Model.upload()`\n\n, the SDK found the bucket, skipped creation, and began uploading model artifacts silently to attacker-controlled storage. No alerts. No errors.\n\n## The Race: 2.5 Seconds Was All It Took\n\nGetting the model file into the attacker’s bucket was only half the attack. The payload delivery required speed.\n\n[Unit 42’s research](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/) measured a window of approximately 2.5 seconds between the victim’s upload completing and Vertex AI’s service agent reading the file. The researchers set up a Cloud Function on the attacker’s bucket that fired on every `storage.object.finalize`\n\nevent. In their proof of concept, the function replaced the victim’s legitimate model with a poisoned version in 1.4 seconds — well inside the window, every time.\n\nThe poisoned file was a crafted pickle object. Python’s `pickle`\n\nmodule executes arbitrary code on deserialization — a behavior that has been a known risk for years, and one the ML ecosystem largely hasn’t moved away from. When Vertex AI loaded the swapped model for serving, the attacker’s code ran inside Google’s infrastructure, within the victim’s project context.\n\n## What Attackers Could Do From There\n\nRemote code execution inside a serving container isn’t a dead end. Unit 42’s proof of concept demonstrated credential theft through the serving container’s service account token, which carried broad cloud-platform scope. From there: access to other GCP services, cross-tenant data exposure, exfiltration of the victim’s original model, and lateral movement within the project.\n\nThe more dangerous version is silent model poisoning. A compromised model deployed without the victim’s knowledge continues serving requests — but its outputs can be manipulated, backdoored, or made to leak data from users. There’s no error, no crash, no alert. The model just does something different than what you trained it to do.\n\n## Check Your Version and Upgrade\n\nThe fix is straightforward. Run this to check and upgrade:\n\n```\n# Check your installed version\npip show google-cloud-aiplatform\n\n# Upgrade to the patched version\npip install \"google-cloud-aiplatform>=1.148.0\"\n```\n\nGoogle shipped two patches: v1.144.0 (March 31) added a random UUID to bucket names, and **v1.148.0 (April 15)** added explicit bucket ownership verification. Both are required — the first fix alone was insufficient, as an attacker who squatted *before* the UUID-based name was generated could still intercept the upload.\n\nIf you can’t upgrade right now, specify your own staging bucket explicitly in every `Model.upload()`\n\ncall:\n\n```\nmodel = aiplatform.Model.upload(\n    display_name=\"my-model\",\n    artifact_uri=\"gs://my-bucket/model/\",\n    staging_bucket=\"gs://your-own-staging-bucket\",  # explicit — don’t let the SDK decide\n)\n```\n\n## The Bigger Problem: SDK Magic Creates Invisible Infrastructure\n\nVertex AI’s automatic bucket creation was a convenience feature. Most developers using it had no idea it was happening — it’s abstracted away behind a method call. That invisibility is the actual security problem.\n\nPredictable cloud resource naming isn’t a new attack. [S3 bucket squatting has existed as a pattern since at least 2018](https://thehackernews.com/2026/06/google-vertex-ai-sdk-flaw-let-attackers.html). Unit 42 also documented [model namespace reuse attacks against HuggingFace repositories](https://unit42.paloaltonetworks.com/model-namespace-reuse/) — the same squatting principle applied to model names instead of storage buckets. What’s different now is that AI infrastructure SDKs are silently provisioning cloud resources that developers never audit because they never see them.\n\nThis attack required zero access to the victim’s project and no social engineering. Just a public project ID and a personal GCP account. That’s a low enough bar that it should change how teams think about ML pipelines. [Your training and serving infrastructure deserves the same scrutiny as your application code](https://www.csoonline.com/article/4186193/googles-vertex-ai-sdk-could-allow-rce-through-bucket-squatting.html) — and in most organizations, it gets a fraction of it.\n\nUpgrade to v1.148.0. Audit what your AI tooling is creating on your behalf. Any SDK that auto-provisions cloud resources is worth examining — not to distrust it, but to understand exactly what it’s doing and why.", "url": "https://wpnews.pro/news/cve-2026-2473-google-vertex-ai-sdk-let-attackers-run-your-code", "canonical_source": "https://byteiota.com/vertex-ai-sdk-cve-2026-2473-bucket-squatting-rce/", "published_at": "2026-06-19 06:08:27+00:00", "updated_at": "2026-06-19 06:11:05.352787+00:00", "lang": "en", "topics": ["ai-safety", "ai-infrastructure", "ai-research"], "entities": ["Google Cloud Vertex AI", "Palo Alto Networks Unit 42", "CVE-2026-2473", "Google Cloud Platform"], "alternates": {"html": "https://wpnews.pro/news/cve-2026-2473-google-vertex-ai-sdk-let-attackers-run-your-code", "markdown": "https://wpnews.pro/news/cve-2026-2473-google-vertex-ai-sdk-let-attackers-run-your-code.md", "text": "https://wpnews.pro/news/cve-2026-2473-google-vertex-ai-sdk-let-attackers-run-your-code.txt", "jsonld": "https://wpnews.pro/news/cve-2026-2473-google-vertex-ai-sdk-let-attackers-run-your-code.jsonld"}}