Este caso es incómodo porque no depende de “hackear Google”, sino de algo que vemos a menudo en compañías: pipelines de Vertex AI que tratan un nombre de bucket como si fuera una referencia segura. Si el bucket no existe en el momento en que el pipeline se despliega/ejecuta, alguien más puede crearlo (en su propio proyecto) y “ocupar” ese nombre. A partir de ahí, cualquier componente que empuje artefactos o lea datasets/modelos desde ubicaciones asumidas puede acabar operando sobre recursos controlados por el atacante.
El impacto práctico no se limita a exfiltración. En MLOps, el daño real suele ser doble: por un lado, ejecución de código en jobs/containers que consumen artefactos manipulados; por otro, envenenamiento de modelos (datasets, features, pesos, artefactos de evaluación) con efectos persistentes y difíciles de detectar. CVE-2026-2473 se asocia precisamente a este patrón de abuso: “predecir” nombres de buckets y convertir esa suposición en control de la cadena de suministro de ML.
Qué salió mal: el nombre del bucket se trató como un control de seguridad
El fallo de fondo es operativo: en vez de definir explícitamente recursos de Cloud Storage bajo control del proyecto (y validar su existencia/propiedad), el pipeline asume rutas “convencionales” del tipo gs://<algo-predecible>/…. En entornos corporativos, esa predictibilidad suele venir de estándares internos (prefijos por entorno, región, unidad de negocio) o de plantillas de IaC compartidas.
Cuando esa convención se combina con automatización que crea referencias antes de crear el bucket (o que no falla si el bucket no existe), aparece la ventana: el atacante “ocupa” el nombre creando el bucket en otro proyecto y espera a que el sistema corporativo escriba o lea. El resultado típico es que se consumen artefactos que no pertenecen al perímetro, algo especialmente grave si el pipeline ejecuta código (por ejemplo, scripts de preprocesado, custom training, contenedores con entrypoints flexibles) o si “promueve” modelos basándose en métricas manipulables.
En empresa esto se manifiesta de forma sutil: el job “funciona”, pero la procedencia del dato cambia. Los equipos ven métricas inestables, evaluaciones incoherentes o un comportamiento extraño en inferencia días después, porque el modelo ya quedó contaminado.
Superficie de ataque específica en Vertex AI: dónde se engancha el squatting
Vertex AI orquesta trabajos que leen y escriben continuamente en Cloud Storage: datasets exportados, artefactos de pipeline, outputs de entrenamiento, modelos empaquetados, logs y métricas. Si alguna de esas rutas apunta a un bucket no controlado y el proceso tiene permisos para interactuar con él, el atacante puede influir en lo que el job descarga o en lo que otros componentes consumen después.
Lo delicado es que el riesgo no solo está en “subir un fichero malicioso”. En ML, un dataset adulterado puede pasar controles superficiales (esquema correcto, tamaños razonables) y aún así sesgar resultados. Y si el pipeline construye imágenes/paquetes o descarga dependencias/artefactos desde rutas en GCS, el salto a ejecución de código remoto es realista: basta con que el job ejecute algo que el atacante pueda reemplazar (scripts, notebooks convertidos, wheels, tarballs, incluso configuraciones que activen paths de ejecución).
- Artefactos de pipeline y componentes reutilizables: si un componente descarga un paquete o script desde un bucket asumido, el atacante puede sustituirlo por uno que ejecute comandos dentro del job.
- Datasets y features: adulterar datos de entrenamiento o validación puede forzar degradación, puertas traseras o “model drift” inducido, que en producción se interpreta como problema de datos interno.
- Model registry y promoción: si la pipeline registra/promueve modelos desde rutas externas, un atacante puede “colar” un modelo aparentemente válido que luego se despliega.
En operaciones, el daño se amplifica porque muchas organizaciones separan responsabilidades: Data/ML define rutas y lógica; Cloud/Sec gestiona permisos e infraestructura. El squatting explota ese hueco de coordinación: la referencia a un bucket predecible se cuela como “detalle de implementación” y no como decisión de seguridad.
Señales tempranas y validación operativa: cómo detectarlo antes de que escale
La detección efectiva no suele venir de un IDS “clásico”, sino de disciplina en trazabilidad de almacenamiento. Si un job de Vertex AI accede a buckets fuera del proyecto esperado, o a buckets con etiquetas/propietarios no corporativos, es una señal fuerte. En incidentes reales, las primeras pistas suelen ser anomalías de acceso: errores intermitentes, cambios de latencia al leer de GCS, o aparición de objetos que “nadie” generó.
También es frecuente que el primer síntoma sea funcional: métricas de entrenamiento que mejoran “demasiado” o empeoran sin explicación, datasets con distribución rara, o un modelo que pasa validación offline pero falla en tráfico real. En contextos regulados, esto se convierte en un problema de auditoría: no puedes demostrar lineage completo si parte del artefacto vino de un bucket no gobernado.
- Audita accesos a Cloud Storage por identidad: revisa qué service accounts de Vertex AI están accediendo a qué buckets y desde qué jobs. Si ves buckets “externos” al proyecto o sin etiquetas corporativas, trátalo como incidente.
- Verifica la propiedad del bucket antes de ejecutar: si tu pipeline recibe URIs, valida que el bucket pertenece a un project allowlist y que cumple políticas (UBLA, retención, logging).
- Comprueba el lineage de artefactos: si un modelo se registró desde una ruta GCS, exige evidencia automática (metadata) de que esa ruta está dentro del perímetro esperado.
El objetivo no es “monitorizar más”, sino monitorizar mejor: menos señales genéricas y más controles deterministas sobre qué ubicaciones son válidas para entradas/salidas del pipeline.
Cómo hacerlo en la práctica: hardening en GCS e IAM para cortar el vector
La mitigación práctica empieza por eliminar la ambigüedad: los buckets que usa Vertex AI deben existir antes, estar en proyectos controlados, con naming no adivinable para recursos sensibles, y con políticas que impidan accesos no esperados. Si tu pipeline “crea si no existe” o acepta cualquier URI, estás dejando el perímetro a merced de convenciones.
A nivel de permisos, aplica el principio de mínimo privilegio a service accounts de Vertex AI: separar identidades para lectura de datasets, escritura de outputs y promoción/registro. Esto reduce el blast radius: incluso si un componente lee algo malicioso, no debería poder publicar artefactos como “oficiales” ni escribir en ubicaciones que luego consumen otros entornos (por ejemplo, dev influyendo en prod).
Controles concretos recomendables (ejemplos de configuración):
- Uniform Bucket-Level Access (UBLA) y eliminación de ACLs: habilita UBLA para que el control pase por IAM y no por ACLs heredadas difíciles de auditar. En práctica, esto reduce configuraciones “accidentales” que abren lectura pública o permisos inconsistentes entre objetos.
- IAM por bucket con roles mínimos: asigna a la service account del job únicamente storage.objectViewer en buckets de entrada y storage.objectCreator/storage.objectAdminstorage.admin a nivel proyecto para identidades de ejecución de ML.
- Validación de pertenencia del bucket: en el código/plantilla del pipeline, añade un check que resuelva el project del bucket y lo compare contra una allowlist corporativa (por ejemplo, “solo proyectos bajo la organización X y carpeta Y”). Si no pasa, el job falla antes de procesar.
Cómo validarlo en operación: toma un job representativo de Vertex AI y revisa, con inventario y auditoría, que todas las URIs GCS usadas (inputs/outputs/model artifacts) pertenezcan a proyectos esperados. Si tienes un catálogo interno de buckets aprobados, obliga a que el pipeline solo pueda referenciar esos IDs; si no existe, créalo: es un control simple que evita incidentes complejos.
Recomendaciones para entornos corporativos
Este escenario (bucket squatting ligado a Vertex AI y CVE-2026-2473) se vuelve posible cuando la organización confunde “convención” con “control”: nombres predecibles de buckets, URIs aceptadas sin validación y pipelines que no verifican propiedad/identidad del almacenamiento. En MLOps, eso abre la puerta tanto a ejecución de código en jobs como a envenenamiento silencioso de datasets y modelos.
Las medidas más efectivas en empresas no son genéricas: precrear y gobernar buckets, reducir permisos de service accounts por función, y añadir validaciones deterministas de pertenencia de bucket/proyecto dentro del pipeline. Complementa con auditoría de accesos centrada en identidades de Vertex AI y revisión rutinaria de lineage de artefactos para que cualquier desviación de almacenamiento sea visible y accionable.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.