Google ha solucionado una falla de seguridad en el SDK de Vertex AI para Python que podría permitir a un atacante secuestrar la carga de un modelo de aprendizaje automático y ejecutar código en la infraestructura de servicio de Google. El asunto, revelado porPalo Alto Networks Unit 42, afectó la forma en que el SDK manejó los depósitos provisionales temporales de Cloud Storage durante las cargas de modelos.
El error afectó a lapaquete google-cloud-aiplatformcuando los desarrolladores confiaban en el comportamiento predeterminado del depósito de preparación. Google completó la solución en la versión 1.148.0, lanzada el 15 de abril de 2026, y los desarrolladores deben actualizar a esa versión o posterior.
El ataque no requirió acceso al proyecto Google Cloud de la víctima. Según los investigadores, un atacante necesitaba un proyecto propio de Google Cloud, el ID del proyecto de la víctima y una condición de carrera durante el proceso de carga del modelo.
Por qué el grupo de preparación predeterminado generaba riesgos
La falla se centró en la denominación predecible de los depósitos. Los nombres de los depósitos de Google Cloud Storage viven en un espacio de nombres global compartido y elDocumentación del depósito de Cloud Storageestablece que cada nombre de depósito debe ser globalmente único.
Cuando un desarrollador no configuró un depósito de prueba personalizado, las versiones vulnerables del SDK generaron un nombre de depósito predeterminado a partir del ID del proyecto y la región. ElModelo.cargar documentaciónincluye un parámetro staging_bucket, pero la ruta riesgosa apareció cuando ese parámetro no se estableció.
El SDK verificó si el nombre del depósito generado existía, pero no verificó que el depósito perteneciera al proyecto de la víctima. Eso permitió a un atacante crear primero el depósito esperado y esperar a que el SDK de la víctima cargara archivos de modelo en el depósito controlado por el atacante.
| Asunto | Qué pasó | Impacto en la seguridad |
|---|---|---|
| Nombre de depósito predecible | El SDK generó un nombre de depósito provisional a partir del ID del proyecto y la región. | Un atacante podría adivinar y crear previamente el depósito. |
| Falta el cheque de propiedad | El SDK verificó si el depósito existía, no si el usuario era propietario. | La víctima podría cargar artefactos modelo en un depósito propiedad del atacante. |
| Ventana de reemplazo de modelo | El atacante tuvo un breve período para cambiar el modelo subido. | Un modelo envenenado podría ejecutar código durante la implementación. |
Cómo funcionó el ataque Pickle in the Middle
La Unidad 42 nombró la técnica Pickle in the Middle porque la prueba de concepto utilizó archivos modelo Python que se basaban en la serialización pickle o joblib. ElDocumentación de pepinillo de Pythonadvierte que los datos maliciosos de pickle pueden ejecutar código arbitrario cuando se cargan.
En elUnidad 42 de investigación, el atacante creó el depósito previsto de antemano y lo configuró para que la víctima pudiera cargarlo. Cuando la víctima cargó un modelo legítimo, una función en la nube activada por la carga reemplazó el archivo con un modelo malicioso antes de que Vertex AI lo leyera.
La ventana de tiempo era ajustada. La Unidad 42 midió aproximadamente 2,5 segundos entre la carga del modelo y la lectura del archivo por parte del agente de servicio de Vertex AI. En la prueba de concepto, el reemplazo se produjo después de aproximadamente 1.433 milisegundos.
- La víctima cargó un modelo a través del SDK sin configurar staging_bucket.
- El SDK utilizó el depósito propiedad del atacante porque el nombre esperado del depósito ya existía.
- Una función de nube detectó la carga y reemplazó el artefacto del modelo.
- Posteriormente, Vertex AI cargó el modelo envenenado durante el despliegue.
- La carga útil maliciosa se ejecutó dentro del contenedor de servicio.
A qué podría acceder el atacante
La prueba de concepto mostró que la carga útil podía consultar el servidor de metadatos de Google Compute Engine desde el interior del contenedor de servicio. Luego extrajo los detalles de la cuenta de servicio y envió el token OAuth a un punto final controlado por el atacante.
En el entorno de prueba de la Unidad 42, el token tenía acceso más allá de la única implementación comprometida. Los investigadores dijeron que podría alcanzar otros artefactos modelo en el mismo proyecto de inquilino administrado por Google, incluido un modelo completo de TensorFlow con pesos entrenados.
El mismo token también expuso información que podría respaldar ataques posteriores, incluidos metadatos de BigQuery, listas de acceso a conjuntos de datos, registros de inquilinos, nombres de clústeres de Google Kubernetes Engine, rutas de imágenes de contenedores internos e identidades de Kubernetes.
| Posible exposición | Por qué es importante |
|---|---|
| Artefactos modelo | Los atacantes podrían robar archivos de modelos entrenados de otras implementaciones en el mismo proyecto de inquilino. |
| Metadatos de BigQuery | Los nombres de los conjuntos de datos y las listas de acceso podrían revelar estructuras de datos confidenciales e identidades de servicios. |
| Registros de inquilinos | Los registros podrían revelar detalles de infraestructura y implementación interna. |
| GKE y rutas de contenedores | Los nombres de las infraestructuras podrían ayudar a los atacantes a mapear el entorno para su posterior movimiento. |
¿Quién necesita actualizar?
Los desarrolladores y los equipos de seguridad deben verificar todos los entornos donde se ejecuta Vertex AI SDK para Python. Esto incluye cuadernos, trabajos de CI, canales de formación, scripts de automatización y servicios de producción.
ElHistorial de lanzamientos de PyPImuestra que la versión 1.148.0 se lanzó el 15 de abril de 2026, y las versiones más nuevas estarán disponibles posteriormente. Cualquier entorno que ejecute versiones anteriores debe considerarse como si necesita revisión.
Los equipos también deben establecer un grupo de preparación explícito que controlen. Google CloudReferencia del SDK de IA de Vertexdocumenta staging_bucket como un parámetro opcional para la carga de modelos, pero su uso elimina la dependencia del comportamiento predeterminado riesgoso en versiones anteriores del SDK.
- Actualice google-cloud-aiplatform a la versión 1.148.0 o posterior.
- Utilice una ubicación controlada de Cloud Storage para preparar los artefactos del modelo.
- Audite cuadernos, máquinas de desarrolladores locales, ejecutores de CI y trabajos de capacitación.
- Revise cualquier flujo de trabajo de carga de modelos que utilice la configuración predeterminada del SDK.
- Evite cargar archivos pickle o joblib de fuentes que no sean de confianza o manipuladas, ya quedocumentación de Pythonrecomienda.
La solución de Google y el error anterior de Vertex AI
Google cambió por primera vez la rutina de denominación del depósito en la versión 1.144.0 agregando un UUID aleatorio al nombre del depósito. La solución completa llegó en la versión 1.148.0, donde elregistro de cambios de la plataforma python-aidice que Google agregó la verificación de propiedad del depósito para evitar la ocupación del depósito en Model.upload().
Lo mismoRegistro de cambios del SDKenumera la versión 1.148.0 como una versión del 15 de abril de 2026. Eso coincide con el cronograma de divulgación de la Unidad 42, que dice que la segunda solución llegó a producción ese día.
Este problema es independiente del CVE-2026-2473, que afectó a Vertex AI Experiments. de googleboletín de seguridaddescribe esa falla anterior como un problema de nomenclatura de depósito predecible que afecta a las versiones 1.21.0 hasta la 1.133.0, pero no la incluye.
cuanto antesBoletín de Google Clouddice que CVE-2026-2473 podría permitir la ejecución remota de código entre inquilinos, el robo de modelos y el envenenamiento mediante la okupación de depósitos. Google dice que no fue necesaria ninguna acción del cliente para ese problema separado porque ya se habían aplicado mitigaciones.
Por qué esto es importante para la seguridad de la IA
La falla muestra cómo los riesgos de seguridad de la IA pueden comenzar en los flujos de trabajo normales de los desarrolladores, no solo en los modelos implementados o las API públicas. Un proceso de carga de modelos que parecía rutinario podría convertirse en un camino de la cadena de suministro hacia una infraestructura de servicios administrada.
También destaca por qué la denominación de depósitos, la preparación de artefactos y la serialización de modelos merecen una revisión de seguridad. En las canalizaciones de IA, un archivo de modelo puede actuar como código si el tiempo de ejecución lo deserializa mediante formatos como pickle o joblib.
Para las organizaciones que utilizan Vertex AI, la prioridad es clara: actualizar el SDK, dejar de depender del comportamiento de preparación predeterminado en entornos más antiguos y asegurarse de que los artefactos del modelo se muevan solo a través de ubicaciones de almacenamiento confiables.
Preguntas frecuentes
¿Cuál fue la falla del SDK de Google Vertex AI?
La falla afectó la forma en que el SDK de Vertex AI para Python seleccionó un depósito de prueba predeterminado de Cloud Storage durante las cargas de modelos. Las versiones anteriores usaban nombres de depósito predecibles y no verificaban la propiedad del depósito, lo que podía permitir que un atacante secuestrara la ruta de carga.
¿Qué versión del SDK de Vertex AI soluciona el problema?
Google completó la solución en la versión 1.148.0 de google-cloud-aiplatform, lanzada el 15 de abril de 2026. Los desarrolladores deben actualizar a la versión 1.148.0 o posterior.
¿Qué necesitaba un atacante para explotar la falla?
Un atacante necesitaba su propio proyecto de Google Cloud, el ID del proyecto de la víctima y un flujo de trabajo de la víctima que cargara un modelo sin establecer un staging_bucket explícito. El depósito de preparación predeterminado de la víctima también tenía que estar ausente en esa región.
¿Por qué el pepinillo hizo que el ataque fuera más peligroso?
Los archivos Pickle y joblib pueden ejecutar código cuando se cargan si contienen datos serializados maliciosos. En la prueba de concepto, el atacante reemplazó el modelo cargado por la víctima con un modelo serializado malicioso que se ejecutó durante la implementación.
¿Cómo pueden los desarrolladores reducir el riesgo?
Los desarrolladores deben actualizar google-cloud-aiplatform a la versión 1.148.0 o posterior, establecer un staging_bucket explícito que controlen, auditar todo el uso del SDK en notebooks y canalizaciones, y evitar cargar artefactos pickle o joblib que no sean de confianza.