This case is uncomfortable because it does not depend on “hacking Google”, but on something we often see in companies: Vertex AI pipelines that treat a bucket name as if it were a safe reference. If the bucket does not exist at the moment the pipeline is deployed/run, someone else can create it (in their own project) and “occupy” that name. From there, any component that pushes artifacts or reads datasets/models from assumed locations can end up operating on resources controlled by the attacker.
The practical impact is not limited to exfiltration. In MLOps, the real damage is usually twofold: on the one hand, code execution in jobs/containers that consume manipulated artifacts; on the other, model poisoning (datasets, features, weights, evaluation artifacts) with persistent effects that are difficult to detect. CVE-2026-2473 is associated precisely with this pattern of abuse: “predicting” bucket names and turning that assumption into control of the ML supply chain.
What went wrong: the bucket name was treated as a security control
The underlying failure is operational: instead of explicitly defining Cloud Storage resources under the project’s control (and validating their existence/ownership), the pipeline assumes “conventional” paths of the form gs://<something-predictable>/…. In corporate environments, that predictability often comes from internal standards (prefixes by environment, region, business unit) or from shared IaC templates.
When that convention is combined with automation that creates references before creating the bucket (or that does not fail if the bucket does not exist), the window appears: the attacker “occupies” the name by creating the bucket in another project and waits for the corporate system to write or read. The typical result is that artifacts that do not belong to the perimeter are consumed, something especially serious if the pipeline executes code (for example, preprocessing scripts, custom training, containers with flexible entrypoints) or if it “promotes” models based on manipulable metrics.
In an enterprise this manifests subtly: the job “works”, but the data provenance changes. Teams see unstable metrics, inconsistent evaluations, or strange behavior in inference days later, because the model has already been contaminated.
Vertex AI-specific attack surface: where squatting hooks in
Vertex AI orchestrates jobs that continuously read and write to Cloud Storage: exported datasets, pipeline artifacts, training outputs, packaged models, logs, and metrics. If any of those paths points to an uncontrolled bucket and the process has permissions to interact with it, the attacker can influence what the job downloads or what other components consume later.
The tricky part is that the risk is not only in “uploading a malicious file”. In ML, a tampered dataset can pass superficial controls (correct schema, reasonable sizes) and still bias results. And if the pipeline builds images/packages or downloads dependencies/artifacts from paths in GCS, the jump to remote code execution is realistic: it is enough for the job to execute something the attacker can replace (scripts, converted notebooks, wheels, tarballs, even configurations that enable execution paths).
- Pipeline artifacts and reusable components: if a component downloads a package or script from an assumed bucket, the attacker can replace it with one that runs commands inside the job.
- Datasets and features: tampering with training or validation data can force degradation, backdoors, or induced “model drift”, which in production is interpreted as an internal data problem.
- Model registry and promotion: if the pipeline registers/promotes models from external paths, an attacker can “slip in” an apparently valid model that is then deployed.
In operations, the damage is amplified because many organizations separate responsibilities: Data/ML defines paths and logic; Cloud/Sec manages permissions and infrastructure. Squatting exploits that coordination gap: the reference to a predictable bucket slips in as an “implementation detail” and not as a security decision.
Early signals and operational validation: how to detect it before it escalates
Effective detection does not usually come from a “classic” IDS, but from discipline in storage traceability. If a Vertex AI job accesses buckets outside the expected project, or buckets with non-corporate labels/owners, it is a strong signal. In real incidents, the first clues are often access anomalies: intermittent errors, changes in latency when reading from GCS, or the appearance of objects that “nobody” generated.
It is also common for the first symptom to be functional: training metrics that improve “too much” or worsen without explanation, datasets with a strange distribution, or a model that passes offline validation but fails in real traffic. In regulated contexts, this becomes an audit problem: you cannot demonstrate full lineage if part of the artifact came from an ungoverned bucket.
- Audit Cloud Storage access by identity: review which Vertex AI service accounts are accessing which buckets and from which jobs. If you see buckets “external” to the project or without corporate labels, treat it as an incident.
- Verify bucket ownership before running: if your pipeline receives URIs, validate that the bucket belongs to a project allowlist and that it meets policies (UBLA, retention, logging).
- Check artifact lineage: if a model was registered from a GCS path, require automatic evidence (metadata) that this path is within the expected perimeter.
The goal is not to “monitor more”, but to monitor better: fewer generic signals and more deterministic controls over which locations are valid for pipeline inputs/outputs.
How to do it in practice: hardening in GCS and IAM to cut the vector
Practical mitigation starts by removing ambiguity: the buckets Vertex AI uses must exist beforehand, be in controlled projects, with non-guessable naming for sensitive resources, and with policies that prevent unexpected access. If your pipeline “creates if it does not exist” or accepts any URI, you are leaving the perimeter at the mercy of conventions.
At the permissions level, apply the principle of least privilege to Vertex AI service accounts: separate identities for reading datasets, writing outputs, and promotion/registration. This reduces the blast radius: even if a component reads something malicious, it should not be able to publish artifacts as “official” or write to locations that other environments later consume (for example, dev influencing prod).
Concrete recommended controls (configuration examples):
- Uniform Bucket-Level Access (UBLA) and removal of ACLs: enable UBLA so control goes through IAM and not through inherited ACLs that are hard to audit. In practice, this reduces “accidental” configurations that open public read access or inconsistent permissions between objects.
- Bucket-level IAM with minimal roles: assign to the job’s service account only storage.objectViewer on input buckets and storage.objectCreator/storage.objectAdmin only where it is essential for outputs. Avoid storage.admin at the project level for ML execution identities.
- Bucket ownership validation: in the pipeline code/template, add a check that resolves the bucket’s project and compares it against a corporate allowlist (for example, “only projects under organization X and folder Y”). If it does not pass, the job fails before processing.
How to validate it in operations: take a representative Vertex AI job and review, with inventory and audit, that all GCS URIs used (inputs/outputs/model artifacts) belong to expected projects. If you have an internal catalog of approved buckets, require that the pipeline can only reference those IDs; if it does not exist, create it: it is a simple control that prevents complex incidents.
Recommendations for corporate environments
This scenario (bucket squatting tied to Vertex AI and CVE-2026-2473) becomes possible when the organization confuses “convention” with “control”: predictable bucket names, URIs accepted without validation, and pipelines that do not verify storage ownership/identity. In MLOps, that opens the door both to code execution in jobs and to silent poisoning of datasets and models.
The most effective measures in enterprises are not generic: precreate and govern buckets, reduce service account permissions by function, and add deterministic validations of bucket/project ownership inside the pipeline. Complement this with access auditing focused on Vertex AI identities and routine review of artifact lineage so that any storage deviation is visible and actionable.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.