The Next Five Years of ML Supply Chain Attacks Start With Predictable Cloud SDKs

A mid-size fintech company runs a fraud detection model on Vertex AI. The ML team, under pressure to ship, uses the SDK defaults: no custom staging bucket, no custom service account. The project ID fintech-fraud-2026 is visible in their public documentation. An attacker creates fintech-fraud-2026-vertex-staging-us-central1 in their own project. They wait. The victim runs model.upload() after training. The SDK checks if the bucket exists: yes. It uploads the model artifacts. The attacker's Cloud Function triggers, downloads the artifact, appends a pickle payload that steals the compute environment's metadata credentials, and re-uploads. Vertex AI loads the model for serving. The pickle executes. The attacker now has the serving container's GCP metadata token. That token, in the default configuration, has access to BigQuery tables containing transaction records, model training data, and the GKE cluster. The attacker exfiltrates 50GB of labeled transaction data, enough to reverse-engineer the fraud model. The company discovers the breach only when the monthly cloud bill shows unexpected egress to an unknown IP. The incident timeline: 3 minutes from upload to full token theft. No alerts fired because the bucket was 'owned' by the attacker's project and the Cloud Function used a legitimate trigger. The ML team believed they followed best practices by using the SDK. They did not know the SDK's bucket choice was the vulnerability.

During five internal assessment cycles with Vulnox clients between February and May 2026, we observed the following patterns across cloud-native ML environments: 1) 6 out of 10 assessed environments used default staging bucket names for at least one production model deployment. 2) The average gap between upload and load in a real-world test was 1.9 seconds, not the 2.5 seconds reported by Unit 42, because Vertex AI pre-warms containers. That makes the race window even tighter. 3) In one assessment of an e-commerce recommendation system (team size: 8 ML engineers, one platform SRE), the default bucket had been in use for 14 months. The team explicitly said they 'trusted the SDK to handle infrastructure.' This trust extended to not monitoring bucket creation events in the cloud audit logs. 4) Counterintuitive: teams that used Infrastructure-as-Code (Terraform, Pulumi) were actually more likely to use default buckets because they templated the SDK calls without parameterizing the staging bucket argument. 5) Most surprising: three organizations had custom staging buckets, but those buckets were in a shared project controlled by a different team. The attack surface simply shifted from one project to another. The SDK still did not verify ownership of the bucket it was about to write to. The fix in v1.148.0 adds bucket ownership verification, but only for Python SDK. The Node.js and Java SDKs remain unpatched as of June 2026.

If you discover that your model was uploaded to an attacker-controlled bucket, the order of your response determines whether you lose data, credentials, or both. First priority: Revoke the service account's token that was used for the upload. The attacker likely obtained the metadata server token. Force a token refresh by recreating the compute instance or pod. Do not wait to investigate. Every minute the token is valid, the attacker can escalate. Second priority: Audit the attacker's bucket via Cloud Storage logs. The bucket exists in their project. Ask Google Cloud support to identify the project ID. This is possible through support tickets. Do not assume you cannot identify the attacker. The bucket name includes your project ID. Third priority: Rotate all secrets that were accessible from the metadata server token. That includes service account keys for any Cloud Function, Cloud Run, or GKE workload that shared the same metadata endpoint. The token in Unit 42's test could access tenant-wide resources. Assume your token had similar scope. Fourth priority: Check for any model artifacts the attacker might have modified. Re-upload all production models from a known good source. Use hash verification. Fifth priority: Update the SDKs and add bucket ownership verification to all pipelines. This is the fix, but it is not the highest priority during active compromise. The highest priority is revoking the token. Get the order wrong and you could alert the attacker before you cut their access.

The bucket squatting pattern will evolve into automated supply chain poisoning within two years. I predict that by Q3 2028, we will see a worm that scans public-facing documentation, GitHub repos, and error messages for project IDs, then automatically creates predictable staging buckets across multiple cloud providers (AWS S3 bucket names are also globally unique). The worm will wait for the first upload, inject a backdoor, and let the model be served for weeks before triggering. The enabling condition is the increasing use of cloud SDKs in CI/CD pipelines that run without human oversight. The attack does not need to be fast. It can be patient. A second scenario: the same predictable naming pattern exists in other cloud services. AWS SageMaker uses a default S3 bucket with a pattern sagemaker-region-account-id. That pattern is predictable but account-id is six digits plus a dash, so it is harder to guess. However, if an attacker obtains the account ID through a different leak (e.g., a public S3 bucket error message), they can pre-create the bucket in their own account. The enabling condition here is the cross-account bucket name collision. S3 bucket names are globally unique. If SageMaker does not verify ownership before writing, the same attack works. Google's fix to verify bucket ownership is a good start, but the industry-wide problem remains: SDKs assume the namespace is trusted. They should assume it is adversarial.

1. (ML Engineer) Run grep -r 'staging_bucket' $(find . -name '*.py' -o -name '*.ipynb') in your ML codebase. Replace every unset staging bucket with an explicit bucket name that includes a random UUID. Outcome: immediate closure of the default bucket attack vector. 2. (Cloud Security Engineer) Enable storage.buckets.create audit logs and create a log sink with a filter for bucket names matching *-vertex-staging-* or *-sagemaker-*. Set up a Slack alert. Outcome: detect bucket squatting attempts in minutes. 3. (Platform Engineering Lead) Update the Python Vertex AI SDK to v1.148.0 or later across all runtime environments: notebooks, CI pipelines, Cloud Functions. Check the google-cloud-aiplatform version in your lock file. Outcome: limited fix, but necessary patch. 4. (ML Engineer) For any model that is loaded via pickle or joblib in production, add a pre-loading hash check. Store the expected SHA256 of the serialized model file in a separate secure location (e.g., Cloud KMS or a secrets manager). Verify the hash before calling pickle.load(). Outcome: blocks pickle-based code execution even if the file is replaced. 5. (Cloud Security Engineer) Review any custom buckets that were created before the patch. Check bucket IAM policies for unexpected bindings. Use gcloud storage buckets list --project=... and cross-reference with gsutil iam get gs://bucket. Outcome: identify any buckets that might have been pre-created by an attacker. 6. (CISO) Schedule a 30-minute threat model session focused on SDK defaults. Invite the ML team, the platform team, and a cloud security lead. Ask: what other SDKs do we use that create resources with predictable names? Outcome: surfaced counterpart vulnerabilities in other services before they are exploited.