Un fallo crítico en el SDK de Vertex AI permitió secuestrar subidas de modelos con bucket squatting

Un fallo crítico en google-cloud-aiplatform, el SDK de Vertex AI para Python, abría la puerta a secuestrar la subida de modelos si el flujo usaba un bucket de staging por defecto. El ataque, basado en bucket squatting, podía terminar en envenenamiento de modelos y hasta ejecución remota de código al desplegar artefactos manipulados. La mitigación pasa por actualizar el paquete y dejar de depender de buckets predecibles.

Equipos de seguridad han identificado un fallo grave en el SDK de Vertex AI para Python que permitía a un atacante desviar, sin permiso previo, la subida de artefactos de un modelo hacia un bucket controlado por él. El problema afectaba a despliegues en Google Cloud que usaban el flujo por defecto, es decir, aquellos que no configuraban un staging_bucket explícito al registrar o subir modelos en Vertex AI Model Registry.

La clave estaba en un detalle incómodo: el SDK generaba un bucket de staging con un nombre determinista, predecible, y no verificaba de forma fiable que ese bucket perteneciera al proyecto correcto. En la práctica, un tercero podía ‘ocupar’ antes ese nombre en Google Cloud Storage dentro de su propio proyecto. Cuando la víctima iniciaba la subida, el proceso acababa escribiendo los artefactos en el bucket del atacante. No hacía falta acceder al proyecto objetivo, bastaba con conocer el project ID, un dato que a veces se deduce por convenciones internas, repositorios, documentación o configuraciones expuestas.

El secuestro no se quedaba en un simple desvío de ficheros. El atacante podía interceptar el artefacto y sustituirlo en una ventana muy corta, en pruebas se observó un margen de unos 2,5 segundos, antes de que el service agent de Vertex AI lo consumiera. Esa condición de carrera elevaba la complejidad, pero también acotaba el trabajo defensivo, porque bastaba una única subida comprometida para dejar un modelo envenenado listo para desplegar.

El riesgo más serio aparece cuando el flujo de ML carga objetos serializados en Python. Formatos habituales como pickle o joblib simplifican el trabajo en ciencia de datos, pero también abren la puerta a ejecutar código durante la deserialización si alguien manipula el contenido. En este escenario, el atacante no solo ‘cambia un modelo’, también puede preparar un artefacto diseñado para disparar RCE cuando la infraestructura de serving lo cargue. A partir de ahí, el impacto se amplía: acceso a secretos del entorno, robo de tokens con permisos amplios, y posible movimiento lateral dentro del proyecto y de servicios gestionados.

La incidencia afectó a google-cloud-aiplatform en versiones 1.139.0 y 1.140.0, y también a flujos relacionados como Vertex AI Experiments cuando dependían de buckets por defecto predecibles. Google introdujo mitigaciones en versiones posteriores del SDK, centradas en la verificación de propiedad del bucket y en evitar que el staging se resuelva hacia recursos fuera del control de la organización.

La prioridad defensiva consiste en actualizar google-cloud-aiplatform a 1.148.0 o superior, y asegurarse de que esa versión mínima queda fijada en CI, notebooks y entornos de ejecución. También conviene dejar de depender del staging por defecto: definir staging_bucket de forma explícita en un bucket propio, con IAM restrictivo, aislamiento por proyecto y, cuando aplique, por región. En paralelo, toca auditar pipelines y scripts que invoquen Model.upload o métodos equivalentes para localizar usos sin staging_bucket.

La última capa es menos cómoda pero igual de necesaria: revisar el uso de pickle y joblib en el ciclo de vida del modelo. Si la integridad del artefacto no queda garantizada extremo a extremo, cualquier fichero serializado debe tratarse como entrada potencialmente maliciosa. Si existe sospecha de manipulación, lo prudente pasa por rotar credenciales, revisar logs y vigilar escrituras inusuales en buckets de staging, sobre todo tras despliegues recientes donde ese bucket no estaba provisionado de antemano.

Más información

• Palo Alto Networks Unit 42 – Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE : https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/
• Focal Security – Kicking the Bucket: Critical RCE and Cross-Tenant Exploits in 3 Different GCP Products : https://focalsecurity.io/blog/kicking-the-bucket-gcp-cross-tenant/
• Mallory – Critical Vertex AI SDK Flaw Enabled Cross-Tenant RCE via Model Upload Hijacking : https://www.mallory.ai/stories/019ed01d-0e39-7bb1-a993-09e2bbe8e06a
• BackBox.org News – Google Vertex AI SDK Flaw Let Attackers Hijack Model Uploads via Bucket Squatting : https://news.backbox.org/2026/06/16/google-vertex-ai-sdk-flaw-let-attackers-hijack-model-uploads-via-bucket-squatting/

La entrada Un fallo crítico en el SDK de Vertex AI permitió secuestrar subidas de modelos con bucket squatting se publicó primero en Una Al Día.