2,5 segundos para hackear: nombres previsibles de buckets de Google facilitaron a los hackers el acceso a modelos de IA

Los servicios en la nube para aprendizaje automático a menudo ocultan una infraestructura compleja tras unas pocas líneas de código, y fue precisamente esa automatización la que creó una amenaza en Google Vertex AI SDK para Python. Los especialistas de Palo Alto Networks Unit 42 identificaron una vulnerabilidad que permitía a un tercero interceptar la carga de un modelo y ejecutar código dentro de la infraestructura de servicio de Google.

El problema surgía cuando el desarrollador no especificaba su propio bucket intermedio de Cloud Storage para subir el modelo. El SDK generaba por sí mismo el nombre del almacenamiento siguiendo un esquema predecible basado en el identificador del proyecto y la región, y luego comprobaba únicamente la existencia del bucket, no su propietario. Dado que los nombres de los buckets en Cloud Storage son globalmente únicos, un atacante podía crear con antelación el bucket necesario en su propio proyecto.

Tras dicha toma, el SDK de la víctima enviaba los archivos del modelo al bucket ajeno. Luego el atacante sustituía rápidamente el modelo subido por una versión maliciosa. El riesgo se agravaba por los mecanismos habituales de Python como pickle y joblib: esos archivos pueden ejecutar código al cargarse si contienen lógica maliciosa oculta.

Unit 42 verificó el escenario en un entorno de prueba. Entre la carga del modelo y la lectura del archivo por Vertex AI transcurrían unos 2,5 segundos. En la demostración, una Cloud Function se activaba tras la carga y reemplazaba el modelo en 1,4 segundos, es decir, antes de que Vertex AI llegara a leer el archivo original. Tras su ejecución, el modelo sustituido robaba el token OAuth desde el servidor de metadatos del contenedor que atendía el servicio.

En la prueba, el token obtenido abría acceso no solo al despliegue comprometido. A través de él se pudieron obtener detalles sobre otros artefactos de modelos en el mismo proyecto gestionado de Google, incluyendo un modelo de TensorFlow con pesos entrenados, los metadatos de BigQuery, listas de acceso, registros, nombres de clústeres de GKE y rutas internas de imágenes de contenedor. Unit 42 no encontró indicios de ataques reales.

El ataque funcionaba solo bajo dos condiciones: el bucket intermedio estándar de la víctima aún no existía en la región seleccionada, y el parámetro staging_bucket permanecía vacío. Google recibió el informe el 5 de marzo de 2026, añadió un uuid4 aleatorio a los nombres de los buckets en la versión 1.144.0 del 31 de marzo y completó la corrección en la versión 1.148.0 del 15 de abril, donde se añadió la verificación del propietario del bucket en Model.upload().

Se recomienda a los usuarios de Google Vertex AI SDK para Python actualizar google-cloud-aiplatform a la versión 1.148.0 o posterior, especificar explícitamente staging_bucket en un Cloud Storage controlado y comprobar las versiones del SDK en todos los entornos de ejecución, incluidos los cuadernos, las tareas de integración continua (CI) y las canalizaciones de entrenamiento.