Pickle in the Middle : RCE via le SDK Python de Vertex AI

Pickle in the Middle : hijacking de modèles ML sans accès au projet cloud de la victime

En juin 2026, l'équipe Unit 42 de Palo Alto Networks a publié le rapport complet d'une faille critique affectant le SDK Python officiel de Google Cloud Vertex AI. Baptisée Pickle in the Middle — en référence au format de sérialisation Python pickle et aux attaques de type man-in-the-middle — cette Vertex AI SDK vulnérabilité modèle ML permettait à un attaquant dépourvu de tout accès initial au projet cloud d'exécuter du code arbitraire sur les machines des data scientists. Le vecteur exploité tient à la désérialisation automatique des artefacts de modèles téléchargés depuis un bucket de stockage, sans vérification d'intégrité ni contrôle d'origine. Cette découverte illustre une problématique désormais structurante pour les équipes MLOps : la chaîne d'approvisionnement des modèles d'apprentissage automatique constitue une surface d'attaque encore largement sous-estimée en entreprise.

Le mécanisme repose sur une faiblesse dans la logique de génération des noms de buckets Cloud Storage temporaires utilisés lors des uploads de modèles. Lorsqu'un utilisateur du SDK Vertex AI ne spécifie pas explicitement un bucket de destination, le SDK génère automatiquement un nom basé sur une combinaison prévisible : l'identifiant du projet GCP et la région de déploiement. Ce pattern déterministe est visible dans le code source open source du SDK, accessible publiquement sur GitHub.

Un attaquant souhaitant exploiter cette vulnérabilité n'avait qu'à identifier sa cible, déduire le nom probable du bucket temporaire à partir de l'identifiant de projet — parfois récupérable via des fuites de configuration ou de l'OSINT — et créer ce bucket dans son propre projet GCP avant que la victime ne l'utilise. Cette technique, le bucket squatting, est analogue au typosquatting de domaines ou au name squatting de packages npm, mais appliquée au stockage cloud. La création d'un bucket GCP dans un projet personnel est accessible gratuitement, ce qui rend la barrière à l'entrée particulièrement basse pour les attaquants.

Le scénario d'exploitation se déroule en plusieurs étapes précises. Lorsque la victime exécute son pipeline de déploiement, le SDK Vertex AI génère le même nom de bucket prévisible et y téléverse automatiquement les artefacts du modèle sans détecter que le bucket appartient à un projet tiers. L'attaquant, qui contrôle ce bucket, reçoit les artefacts et les remplace immédiatement par un modèle empoisonné au format pickle. Quand Vertex AI récupère ensuite le modèle pour le déployer dans son infrastructure de serving, le pickle malveillant est désérialisé, déclenchant l'exécution du code arbitraire embarqué dans l'environnement de serving de Google — une RCE cross-tenant sans accès direct au projet cible.

Le choix du format pickle comme vecteur de payload n'est pas anodin. Le format de sérialisation Python pickle est notoirement dangereux dans des contextes non maîtrisés : son mécanisme de désérialisation exécute du code Python arbitraire lors du chargement d'un fichier. Dans l'écosystème ML, pickle est malheureusement le format de sauvegarde par défaut pour PyTorch (via torch.save) et des librairies comme scikit-learn. Les avertissements sur les risques liés à la désérialisation pickle de fichiers de sources non fiables sont documentés depuis des années dans la communauté sécurité, mais la praticité du format a conduit à son adoption généralisée dans les pipelines ML de production.

Les versions vulnérables confirmées par Unit 42 sont 1.139.0 et 1.140.0 du SDK google-cloud-aiplatform. Les chercheurs précisent que l'attaque est réalisable sans aucun accès initial au projet GCP de la victime. Cette caractéristique rend la surface d'attaque particulièrement large : tout projet Vertex AI utilisant des versions vulnérables sans spécifier explicitement un bucket de destination est potentiellement exposé, quelle que soit la robustesse de ses autres contrôles d'accès IAM ou réseau.

La divulgation a suivi le processus de responsible disclosure. Unit 42 a notifié Google via le programme de bug bounty Google Cloud dès la découverte. Google a validé la vulnérabilité et développé un correctif rapidement. Le patch, intégré dans la version 1.148.0 publiée le 15 avril 2026, modifie la logique de génération des noms de buckets pour éliminer la prévisibilité du pattern. Google a par ailleurs communiqué aux utilisateurs concernés via les canaux de notification de Google Cloud Security.

Les recommandations directes d'Unit 42 sont triples : mettre à jour immédiatement le SDK vers la version 1.148.0 ou ultérieure ; toujours spécifier un bucket GCS contrôlé explicitement dans les appels SDK plutôt que laisser la génération automatique ; auditer les modèles déployés via Vertex AI au cours de la période de vulnérabilité en comparant leurs hashes à ceux générés lors de l'entraînement. En cas de doute sur l'intégrité d'un modèle, un reentraînement depuis des artefacts sources vérifiés constitue la seule garantie fiable de sécurité.

Empoisonnement de modèles ML : une menace émergente pour les pipelines IA d'entreprise

La vulnérabilité Pickle in the Middle s'inscrit dans un contexte de prise de conscience progressive des risques liés à la chaîne d'approvisionnement des modèles de machine learning. Alors que les attaques supply chain traditionnelles ciblent les packages logiciels — npm, PyPI, Maven — le vecteur des modèles ML représente une frontière relativement nouvelle mais en expansion rapide. Les modèles IA compromis peuvent produire des prédictions erronées, exfiltrer des données d'inférence, ou — comme dans ce cas — servir de vecteur d'exécution de code dans des environnements cloud managés à fort enjeu.

L'aspect le plus préoccupant est le caractère cross-tenant et sans accès préalable de l'attaque. Les attaques traditionnelles contre les pipelines ML nécessitent généralement un accès au projet cloud de la victime via des credentials compromis, une injection ou une mauvaise configuration IAM. Ici, la vulnérabilité permettait à un attaquant totalement externe d'injecter du code dans l'infrastructure de serving d'une organisation, en exploitant uniquement une faiblesse de conception dans le SDK officiel de Google. Ce type de vecteur peut échapper complètement aux contrôles de sécurité axés sur la protection des accès privilégiés.

Pour les organisations utilisant Vertex AI en production, l'incident soulève des questions sur la traçabilité des modèles déployés. Combien d'équipes ML maintiennent un inventaire précis des hashes de leurs artefacts entre la phase d'entraînement et la phase de serving ? La comparaison des checksums est une pratique recommandée depuis des années mais rarement implémentée en dehors des environnements à très haute criticité. L'incident Vertex AI fournit un argument concret pour l'adoption de ML Model Cards incluant des signatures cryptographiques, à l'image des pratiques Sigstore pour les packages logiciels ou du framework SLSA pour les artefacts de build.

La dimension cloud storage pointe vers un problème systémique : la gestion des ressources temporaires dans les SDK cloud. Les buckets temporaires à noms prévisibles ne sont pas une exclusivité de Vertex AI — ce pattern est présent dans de nombreux SDK de services managés qui créent des ressources de transit à la volée. Une revue proactive de ces patterns dans les SDK AWS SageMaker, Azure Machine Learning et d'autres plateformes ML managées s'impose dans le sillage de cette découverte d'Unit 42, pour identifier des variantes similaires potentiellement non encore divulguées.

Ce qu'il faut retenir

• La faille Pickle in the Middle dans le SDK Python Vertex AI (versions 1.139.0 et 1.140.0) permettait un empoisonnement de modèle ML et une RCE cross-tenant sans accès initial au projet cloud de la victime.
• La mise à jour vers la version 1.148.0 du SDK google-cloud-aiplatform est impérative ; les modèles déployés pendant la période vulnérable doivent être audités via comparaison de checksums.
• Les pipelines ML doivent intégrer la vérification de signatures cryptographiques des artefacts entre génération et déploiement, à l'image des pratiques supply chain logicielle (Sigstore, SLSA).