CVE-2026-2473: Vertex AI Cross-Tenant RCE Flaw Enables Bucket Squatting Attacks Across Cloud Projects

Vertex AI – Cross-Tenant RCE via Bucket Squatting

CVE ID: CVE-2026-2473
Product: Google Vertex AI (Vertex AI Experiments component)
Vulnerability Type: Cross-tenant Remote Code Execution (RCE), Model Theft, Model Poisoning
Root Cause: Predictable Cloud Storage bucket naming (CWE-340 – Predictable Identifier Generation)
CVSS Score: 7.7 (High)
Severity: High
Attack Vector: Network (Remote)
Privileges Required: None
User Interaction: None
Exploit Complexity: Low to Moderate
Exploit Availability: No confirmed public weaponized exploit; technique reproducible for educational validation
Impact: Confidentiality, Integrity, and Availability compromise across tenants

Executive Summary

A design flaw in Vertex AI Experiments allowed predictable Cloud Storage bucket names to be generated automatically for experiment staging. Because Cloud Storage bucket names are globally unique, an attacker could pre-create a bucket with the expected name before the legitimate tenant did.

When the experiment ran, it would interact with the attacker-controlled bucket under the assumption that it was safe and owned by the correct tenant. This opened the door to:

Remote Code Execution (if malicious artifacts were executed)
Model theft (reading trained models written to the bucket)
Model poisoning (injecting tampered artifacts or datasets)
Cross-tenant data leakage

This was not a typical misconfiguration by customers; it originated from how predictable identifiers were generated within the service logic.

Google has addressed the issue through service-side mitigation and SDK updates.

Technical Root Cause

The vulnerability stemmed from deterministic bucket name generation patterns. When experiments were initialized without explicitly defining a secure staging bucket, a naming convention was derived based on project metadata or predictable identifiers.

Since bucket names in Google Cloud Storage are globally unique and not scoped per project, an attacker in a different project could:

Predict the target bucket name.
Create that bucket first.
Wait for the victim’s experiment to use it.
Control or observe object uploads and downloads.

This created a classic bucket squatting scenario in a multi-tenant cloud environment.

Affected Versions

google-cloud-aiplatform Python SDK versions:
- >= 1.21.0 and < 1.133.0

Environments relying on auto-generated experiment staging buckets were most exposed.

Attack Scenario

Step-by-Step Exploitation Flow (Educational)

Enumeration Phase
- Attacker identifies naming pattern used by Vertex AI Experiments.
- Pattern derived from project ID, experiment ID, or static prefix.
Bucket Pre-Creation
- Attacker creates the bucket with predicted name.
Artifact Injection
- Malicious files uploaded:
  - Compromised model artifacts
  - Malicious evaluation scripts
  - Tampered training dataset
  - Serialized payloads designed for execution
Victim Execution
- Vertex AI experiment runs.
- Reads objects from attacker-controlled bucket.
- Malicious artifact processed.
- Code execution triggered within experiment environment.
Post-Exploitation
- Model extraction
- Credential harvesting (if accessible)
- Persistence via artifact replacement
- Backdoored model deployment

Impact Analysis

Confidentiality

Exposure of proprietary models
Leakage of training datasets
Access to experiment metadata

Integrity

Model poisoning
Dataset tampering
Evaluation metric manipulation

Availability

Experiment failure
Pipeline corruption
Repeated job crashes

MITRE ATT&CK Mapping

Initial Access – Exploiting Cloud Resource Misconfiguration
Resource Hijacking
Data Exfiltration from Cloud Storage
Supply Chain / ML Pipeline Poisoning

Indicators of Exploitation

Unexpected bucket ownership outside organization
Experiment referencing unknown staging buckets
Object reads from buckets not owned by project
Sudden model drift without dataset change
Execution logs referencing unfamiliar object URIs
Cloud Audit Logs showing bucket creation from foreign projects

Detection Strategy

Log Sources Required

Cloud Audit Logs (Admin Activity)
Cloud Audit Logs (Data Access)
Cloud Storage access logs
Vertex AI experiment logs
IAM policy change logs

Detection Queries

1. Unexpected Bucket Creation

resource.type="gcs_bucket"
protoPayload.methodName="storage.buckets.insert"
timestamp >= "2026-01-01T00:00:00Z"

Look for:

Buckets matching Vertex experiment naming patterns
Buckets created by unfamiliar principals
Buckets created from external projects

2. Object Writes to Suspicious Buckets

resource.type="gcs_bucket"
protoPayload.methodName="storage.objects.insert"
protoPayload.resourceName:("vertex" OR "experiment")

Monitor:

Objects uploaded shortly before experiment runs
Objects uploaded by non-standard accounts

3. Cross-Project Object Reads

resource.type="gcs_bucket"
protoPayload.methodName="storage.objects.get"
protoPayload.authenticationInfo.principalEmail!~"@yourdomain.com"

Flags external access attempts.

4. Vertex AI Experiment Using Unexpected URI

resource.type="aiplatform.googleapis.com/Experiment"
jsonPayload.message:("gs://")

Investigate:

Buckets outside approved allowlist
Unrecognized staging URIs

5. IAM Permission Abuse

protoPayload.methodName="SetIamPolicy"
protoPayload.serviceData.policyDelta.bindingDeltas.role:"roles/storage"

Review unexpected permission grants.

Detection Logic for SIEM Implementation

Alert when ALL of the following conditions occur:

Bucket created
Name matches Vertex pattern
Created outside expected project
Followed by object write
Followed by Vertex experiment execution

Time window correlation: 24–72 hours.

Proof of Concept (Educational)

No public exploit kit has been released. However, concept validation would involve:

Predicting bucket naming convention
Creating bucket before victim
Uploading benign test artifact
Observing experiment referencing controlled bucket

No exploit payloads are provided here.

In a lab environment, controlled validation should only be performed within authorized test projects.

Response & Remediation

Immediate Actions

Upgrade SDK immediately.
Explicitly define a controlled staging bucket.
Restrict bucket creation permissions.
Audit historical bucket creation logs.
Verify integrity of trained models.
Re-run critical experiments from trusted artifacts.

Hardening Recommendations

Enforce organization policy to restrict public bucket creation.
Require explicit staging bucket configuration.
Use per-project unique random suffix naming.
Enable object versioning.
Enable Bucket Lock where appropriate.
Monitor bucket creation in near real-time.

Patch / Upgrade

Update the Vertex AI SDK:

Upgrade google-cloud-aiplatform to:

>= 1.133.0

Official Security Bulletin & Patch Information:

https://docs.cloud.google.com/support/bulletins#gcp-2026-012

Risk Rating Justification

Although no active mass exploitation has been confirmed, the exploit path is straightforward and requires no authentication. Because it enables cross-tenant compromise in a managed ML platform, impact is significant.

This vulnerability should be treated as high priority in ML production environments.

Final Security Note

Even after patching, monitoring for anomalous bucket activity is strongly recommended. ML supply chains are increasingly targeted, and storage-layer attacks remain one of the simplest yet most damaging vectors in cloud AI systems.