Pickle in the Middle una vulnerabilidad de Vertex AI que permite ejecutar código y robar modelos

Un fallo en el SDK de Python de Google Cloud Vertex AI permitió que un atacante sin credenciales ni acceso previo al proyecto de la víctima secuestrara la carga de un modelo y ejecutara código en la infraestructura de serving de Google. Palo Alto Networks Unit 42 bautizó la técnica como "Pickle in the Middle" y notificó el problema a Google; el fabricante ya ha parcheado el SDK, pero la incidencia deja lecciones importantes sobre riesgos de diseño y prácticas inseguras en pipelines de machine learning.

La raíz técnica fue simple y peligrosa: cuando el SDK necesitaba un bucket temporal para subir artefactos de modelo y el usuario no especificaba uno, generaba un nombre predecible a partir del ID del proyecto y la región —por ejemplo project-vertex-staging-region— y verificaba únicamente si existía, no si el bucket pertenecía al proyecto del usuario. Como los nombres de buckets son globalmente únicos, un atacante con su propio proyecto podía crear primero ese bucket y esperar la subida de la víctima. El atacante entonces reemplazaba el contenido subido por un artefacto malicioso. Dado que muchos modelos Python se serializan con pickle o joblib —formatos que ejecutan código al deserializar—, cuando Vertex AI cargaba ese modelo el payload del atacante se ejecutaba dentro del contenedor de serving.

La explotación dependía de una ventana de tiempo (TOCTOU): Unit 42 midió un intervalo de aproximadamente 2,5 segundos entre la subida y la lectura por Vertex AI; en su prueba de concepto un Cloud Function reemplazó el objeto en 1,4 segundos y el payload robó un token OAuth desde el servidor de metadatos del contenedor, enviándolo al atacante. Ese token, en el entorno de prueba, tenía permisos más amplios que la simple instancia comprometida: permitió acceder a otros artefactos en el tenant gestionado por Google, incluyendo modelos completos, metadatos de BigQuery, listas de acceso, logs y rutas internas de imágenes de contenedor. Es decir, la explotación podía derivar en ejecución remota de código, robo de modelos y movimiento lateral dentro del tenant.

El vector funcionó solo si concurrían dos condiciones comunes: que el bucket por defecto de staging no existiera en la región (situación habitual en proyectos nuevos) y que el desarrollador no hubiera establecido explícitamente el parámetro staging_bucket. Unit 42 reportó la vulnerabilidad el 5 de marzo de 2026; Google lanzó un arreglo inicial (aleatorizando el nombre con uuid4) y completó la corrección añadiendo una verificación de propiedad del bucket en Model.upload() en la versión 1.148.0 del paquete.

Las implicaciones para equipos de ML y seguridad son amplias: más allá de la pérdida de propiedad intelectual (modelos robados o envenenados), la técnica destaca cómo decisiones de diseño en clientes y defaults inseguros pueden convertirse en vectores de escalada sin phishing ni exploits complejos. También subraya el riesgo de formatos de serialización inseguros en entornos multi-tenant y la necesidad de políticas que eviten la creación de recursos previsibles que puedan ser aprovechados por un competidor o un atacante externo.

Acciones inmediatas recomendadas: actualice el SDK a la versión parcheada con el comando pip (por ejemplo pip install --upgrade google-cloud-aiplatform>=1.148.0) y, muy importante, defina siempre explícitamente staging_bucket como una ubicación de Cloud Storage que usted controle. Compruebe la versión de google-cloud-aiplatform dondequiera que se ejecute: notebooks, CI/CD, pipelines de entrenamiento y entornos de prueba, no solo en producción. Si sospecha que pudo haber exposición antes del parche, considere rotar credenciales y tokens de servicio afectados y revisar el historial de objetos de los buckets públicos o compartidos.

Además de parchear, revise sus prácticas de serialización: si es posible, evite enviar modelos en formatos que ejecuten código en carga como pickle/joblib; prefiera formatos diseñados para despliegue seguro (SavedModel, ONNX o exportaciones que no ejecuten código al cargar). En el plano de control de acceso, limite los permisos asociados a agentes y cuentas de servicio, use Workload Identity y aplique políticas organizacionales que impidan la creación de recursos con nombres previsibles o que obliguen a la vinculación de buckets a proyectos concretos.

Para equipos de respuesta y riesgo, audite logs de Cloud Storage y Vertex AI por operaciones inusuales en las ventanas de carga de modelos, y revise accesos a la metadata server y tokens emitidos por servicios gestionados. Este incidente vuelve a poner sobre la mesa la necesidad de tratar la cadena de suministro de ML como un vector de amenaza: desde el código del cliente hasta los artefactos que se despliegan en producción.

Lea el análisis técnico y la notificación de la investigadora original en la web de Unit 42 para detalles del PoC y tiempos de explotación: Unit 42. Compruebe las notas de lanzamiento y versiones del SDK en el repositorio oficial para confirmar que su entorno está actualizado: python-aiplatform releases y la página del paquete en PyPI: google-cloud-aiplatform on PyPI. Actúe hoy: parchear y fijar el bucket de staging elimina la ventana de ataque conocida; complementarlo con controles de acceso y prácticas de serialización seguras reduce significativamente el riesgo.