Alerte Cloud IA : Une faille RCE "Bucket Squatting" corrigée dans Google Vertex AI!!

Salut à tous les ingénieurs cloud, data scientists et spécialistes de la sécurité des architectures IA,

C’est une découverte technique passionnante mais particulièrement redoutable qui secoue le monde du Cloud et des MLOps en ce 18 juin 2026. Les chercheurs en sécurité de l'Unit42 (Palo Alto Networks) viennent de révéler une faille de conception majeure au sein du SDK Python de Google Vertex AI — la plateforme managée de Google Cloud dédiée à la création et au déploiement d'agents IA.

Cette vulnérabilité permettait à un attaquant d'empoisonner des modèles de deep learning et de déclencher une exécution de code à distance (RCE) cross-tenant (d'un compte client Google Cloud à un autre). Bonne nouvelle : Google a réagi et le correctif est disponible.

Le "Bucket Squatting" : Comment l'attaquant volait l'espace de stockage

Le cœur du problème repose sur une logique défaillante de nommage des espaces de stockage objet (Google Cloud Storage) au sein des versions 1.139.0 et 1.140.0 du SDK Vertex AI pour Python.

Pour stocker temporairement (staging) les artefacts des modèles d'IA lors de leur entraînement ou déploiement, le SDK générait automatiquement un nom de bucket basé uniquement sur l'ID du projet GCP du client et sa région géographique.

L'attaque se déroulait ainsi :

1. L'unicité globale du cloud : Sur Google Cloud, il est impossible que deux buckets portent exactement le même nom, toutes entreprises confondues.

2. La prédiction : Si un attaquant parvenait à deviner ou connaître l'ID du projet d'une victime et sa région, il pouvait créer préventivement le bucket de staging dans son propre projet d'attaquant.

3. Le détournement silencieux : Lorsque la victime lançait son workflow Vertex AI, le SDK vérifiait simplement si le bucket existait, sans en valider la propriété. Le trafic et les modèles de la victime étaient alors redirigés silencieusement vers le bucket contrôlé par l'attaquant.

L'attaque "Pickle in the Middle" : Du cloud à la RCE

Une fois le bucket de la victime "squatté", les chercheurs d'Unit42 ont mis au point un scénario d'exploitation baptisé "Pickle in the Middle" pour exécuter du code sur l'infrastructure de la cible.

En Python, la quasi-totalité des modèles de machine learning sont sauvegardés et sérialisés via les formats Pickle ou Joblib. Or, la désérialisation d'un fichier Pickle comporte une faiblesse structurelle bien connue : elle permet d'exécuter du code arbitraire si le fichier a été modifié.

┌────────────────────────────────────────────────────────┐
│          MÉCANISME DE L'ATTAQUE "PICKLE IN THE MIDDLE"  │
├────────────────────────────────────────────────────────┤
│                                                        │
│  [ Victime : Déploie un Modèle sur Vertex AI ]         │
│                        │                               │
│                        ▼                               │
│  [ Routage silencieux vers le Bucket de l'Attaquant ]  │
│                        │                               │
│                        ▼                               │
│  [ Attaquant : Remplace l'artefact par un Pickle RCE ] │
│                        │                               │
│                        ▼                               │
│  [ Vertex AI : Désérialise et Exécute le code malveillant ] │
│                                                        │
└────────────────────────────────────────────────────────┘

Pendant la courte fenêtre de transfert, l'attaquant remplaçait le modèle légitime par une version empoisonnée. Dès que l'agent de service de Vertex AI récupérait et désérialisait le fichier, le code malveillant de l'attaquant s'exécutait immédiatement sur le tenant de la victime.

Quand l'IA trouve les bugs de l'IA

Détail piquant de cette découverte : pour dénicher cette vulnérabilité dans le code de Google, l'Unit42 a utilisé... une intelligence artificielle.

Les chercheurs ont intégré un grand modèle de langage (LLM) dans leur workflow d'audit de code. En affinant les requêtes de manière itérative, ils ont demandé au LLM de traquer spécifiquement les chemins où les ressources cloud provisionnées étaient influencées par des variables prédictibles (comme l'ID projet). Un processus d'analyse qui prenait autrefois plusieurs jours a pu être bouclé en quelques heures.

Comment se protéger ?

Google a modifié en urgence le workflow de son SDK pour imposer une validation stricte de la propriété des buckets de staging avant toute utilisation. Les correctifs de sécurité ont été poussés dans les branches de production.

Si vous utilisez Vertex AI dans vos pipelines MLOps, vous devez impérativement mettre à jour votre SDK Python vers l'une des versions saines :

• Versions vulnérables : 1.139.0 et 1.140.0

• Versions corrigées : Mettre à jour vers 1.144.0 ou 1.148.0 (ou supérieur).

L'avis du blog :

Cette faille rappelle une règle d'or de la sécurité cloud souvent oubliée par les développeurs : l'existence d'une ressource ne vaut pas autorisation ou propriété. Faire confiance à un nom de bucket de manière aveugle dans un espace de nommage global partagé est une erreur de conception classique, mais qui prend une tout autre dimension lorsqu'elle touche des plateformes d'IA d'entreprise. C'est aussi une belle démonstration de l'arroseur arrosé, où un LLM a été utilisé pour casser la plateforme qui sert justement à construire des LLM. À vos gestionnaires de paquets, il est temps de faire un pip install --upgrade google-cloud-aiplatform !