7 min. Temps de lecture
Pillar Security a signalé le 16 avril 2026 une vulnérabilité dans la CLI Google Gemini, que Google a corrigée le 24 avril dans le cadre du GHSA-wpqr-6v78-jr5g. Score CVSS : 10,0. Un contributeur à partir d’un extranet a pu exécuter du code sur un CI-Runner avant même l’initialisation de la sandbox. Ceux qui utilisent encore la version 0.38 ou antérieure de la CLI Gemini dans leur stack de pipeline rencontrent un problème multi-tenants qui ne se manifeste pas dans la console de leur propre cloud.
Les points clés en bref
- CVSS maximal pour une CLI IA dans un contexte CI. La vulnérabilité de la CLI Gemini combinait deux failles de conception : le mode headless traitait chaque dossier de travail comme s’il s’agissait d’un répertoire confidentiel, tandis que –yolo ignorait les listes d’autorisation des outils. L’ensemble de ces deux mécanismes permettait l’exécution de code à distance.
- Le CI-Runner comme porte d’entrée. Un pull request provenant d’un tiers suffisait pour lire des secrets, des credentials et du code source avant même le démarrage de la sandbox. Cela déplaçait ainsi l’aire d’attaque du portable de l’employé vers la plateforme de build.
- Le patch est disponible, mais sa diffusion reste inconnue. Les versions Gemini-CLI 0.39.1 et google-github-actions/run-gemini-cli 0.1.22 ferment cette branche. Ceux qui ne mettent pas à jour leur système centrallement continuent de faire tourner des versions anciennes dans leurs forks et leurs pipelines privés sans qu’aucun signe d’attaque ne soit détecté.
Connexes :Platform Engineering Compliance NIS2/DORA / Google Gemini dans l’entreprise
Ce que Pillar Security a spécifiquement démontré
Qu’est-ce que la vulnérabilité de la CLI Gemini GHSA-wpqr-6v78-jr5g ? Il s’agit d’une faille d’exécution de code à distance dans la CLI Google Gemini et dans l’action GitHub associée, qui a permis à un contributeur à partir d’un extranet d’exécuter des commandes sur le CI-Runner avant même l’initialisation de la sandbox. Google a évalué cette vulnérabilité avec un score CVSS de 10,0, ce qui correspond à la gravité maximale selon l’échelle CVSS-3.1. Les versions correctives sont Gemini-CLI 0.39.1 et google-github-actions/run-gemini-cli 0.1.22.
La mécanique est nettement plus spécifique que la description habituelle des CVE. Pillar Security a d’abord démontré l’attaque sur le dépôt Google draco, puis directement sur la CLI Gemini le 20 avril. Le déclencheur était un pull request contenant des données de travail préparées. Dans le mode headless de la CLI, le répertoire de travail était traité comme fiable sans aucune confirmation supplémentaire ; une configuration .gemini locale pouvait être chargée, et le mode –yolo ignorait les listes d’autorisation des outils très fines.
Le résultat fut un chemin d’injection de prompt qui conduisit à des commandes shell arbitraires. Le runner considéra cette séquence comme une instruction d’IA légitime, alors que le démarrage de la sandbox arrivait trop tard, les credentials ayant déjà été collectées. Ceux qui opéraient dans un dépôt open-source où les pull requests de contributeurs externes étaient testées de manière routinière ont connu un bypass ouvert pendant des semaines, sans que rien dans le journal d’audit ne révèle l’existence de l’attaque.
Pourquoi cela fait particulièrement mal dans les lunettes multi-locataires
Les architectes cloud connaissent le réflexe du score CVSS à 10 : mains sur la table, plan de correction, audit. Ce qui rend Gemini-CLI particulièrement délicat, c’est sa nature structurelle : il s’exécute dans un contexte CI/CD avec les droits hautement privilégiés de la pipeline. Une pipeline compromise peut ainsi construire des images de conteneurs signées, renouveler des identifiants cloud, déployer des charts Helm ou manipuler les états Terraform.
Ceux qui travaillent sur une plateforme multi-locataires en ressentent d’autant plus l’impact. Un job de pipeline qui produit pour plusieurs clients pourrait, en cas d’exploitation RCE, potentiellement mettre en mouvement des données ou des artefacts de build appartenant à des mandants externes. Quant à un job de pipeline qui ne concerne que son propre mandant mais s’exécute sur une instance Cloud Run partagée, il offre à l’attaquant une cible potentielle pour un mouvement latéral.
Ce n’est pas le premier incident CVSS-10 chez un hyperscaler cette année. Le CVE-2026-32202 a contraint la CISA à inscrire ce problème sur la liste KEV en avril, imposant des délais et une pression accrue aux agences fédérales. L’enseignement est clair : les CLI d’intelligence artificielle sont des logiciels comme n’importe quel autre outil de construction, et ils doivent être soumis au même processus de patching, d’audit et de mise en liste blanche.
Mitigations CI/CD pour les équipes cloud : ce qui aide, ce qui nuit
Ce qui nuit
- Les CLI d’IA utilisant l’option –yolo ou tout mode « trust-all » similaire dans le CI
- Les configurations d’espace de travail issues de pull requests sans étape explicite de validation
- Le pinning sur une branche ou une étiquette plutôt que sur une SHA de commit
- Les identités de pipeline partagées entre plusieurs dépôts
- Les journaux d’audit sans enregistrement préalable de la phase sandbox
Ce qui aide
- La version minimale requise fixée à Gemini-CLI 0.39.1 / Action 0.1.22
- La fédération d’identité de charge de travail au lieu d’utiliser des clés persistantes
- Les jobs de validation des pull requests isolés dans leur propre tenant
- Les listes blanches d’outils, sans aucun flag global « yolo »
- Renovate-Bot ou Dependabot surveillant les versions des CLI d’IA
La colonne de gauche n’est pas théorique. Quiconque a intégré Gemini-CLI dans une action au cours des trois derniers mois devrait aujourd’hui consulter les journaux d’exécution du CI afin d’y repérer des configurations d’espace de travail préparées spécifiquement avant la première action de l’outil. Pillar Security met à disposition une liste d’indicateurs de compromission dans son rapport publié. Cette liste doit être intégrée à votre SIEM personnel avant le début de la prochaine session d’audit.
La fédération d’identité de charge de travail constitue le deuxième levier souvent sous-estimé. Un run de pipeline qui ne tire pas ses identifiants GCP d’un compte de service statique, mais les fédère à chaque exécution via OIDC, n’a pas de jeton persistant à risquer en cas d’exploitation RCE.
Feuille de route des correctifs : de l’audit à une pipeline propre
Deux semaines sont réalistes si l’équipe plateforme s’engage dans l’épinglage strict de la version de l’Action et ne planifie pas parallèlement la prochaine migration de plateforme. Ceux qui gèrent plusieurs tenants devront ajouter, durant les troisième et quatrième semaines, les listes blanches d’outils par mandant, ce qui représente un effort supplémentaire mais n’introduit pas de nouvelle architecture opérationnelle.
Ce qui reste en suspens
Pillar Security a signalé le bug dans le cadre d’un programme de récompenses, sans en divulguer le montant. Cela est courant dans le contexte du VRP de Google et ne donne aucune indication sur la gravité. Plus important encore est le schéma observé : les CLI IA deviennent la première ligne de défense de la sécurité CI, car elles constituent le lien direct entre une entrée de prompt externe et l’exécution shell. La prochaine vague comparable ne concernera probablement pas une CLI, mais une API d’agent intégrée ou une logique de build pilotée par un LLM.
Ainsi, ceux qui appliquent aujourd’hui le correctif à Gemini-CLI résolvent un incident spécifique. Ceux qui reconfigurent simultanément leur pipeline autour de l’identité de charge de travail, des listes blanches d’outils et de la journalisation d’audit pré-bac à sable ferment toute une classe de vulnérabilités.
Foire aux questions
Suis-je concerné si j’utilise Gemini-CLI uniquement en local ?
Le risque dans les pipelines CI headless est nettement plus élevé que lors d’une utilisation locale interactive, car l’étape de confiance (Trust) y fait défaut. En local, c’est le drapeau –yolo qui pose réellement problème. Si vous ne l’avez pas activé localement et utilisez une version inférieure à la 0.39.1, il est malgré tout recommandé de mettre à jour rapidement.
Un verrouillage de version dans l’action GitHub suffit-il ?
Non, pas à lui seul. Un verrouillage de version sur le 0.1.22 ou un SHA constitue la ligne de base. Il faut également des listes autorisées d’outils par tâche et, idéalement, un profil Runner séparé pour les validations de pull request, qui ne conserve aucune identité de service cloud. La défense en profondeur n’est pas ici un slogan théorique, mais une réalité opérationnelle.
Comment savoir si la vulnérabilité a été exploitée ces dernières semaines ?
Pillar Security a publié des indicateurs dans son rapport de divulgation. Concrètement, on recherche dans les journaux d’exécution des configurations .gemini manipulées, chargées juste avant la première opération d’outil, ainsi que des sous-appels shell situés en dehors du périmètre de la liste autorisée attendue. Une remontée historique (lookback) SIEM sur les 30 derniers jours constitue une visibilité minimale appropriée.
Que signifie cela pour les équipes de plateformes multi-locataires ?
La date de correctif s’applique à chaque locataire. Ceux qui peuvent appliquer cette mise à jour de manière centralisée via une mise à jour plateforme sont avantagés. Ceux qui autorisent des pipelines spécifiques à un locataire doivent mettre à niveau chaque locataire individuellement vers la version corrigée et documenter cette action vis-à-vis de l’audit.
Existe-t-il un lien direct avec la KEV de la CISA ?
Actuellement, cette vulnérabilité de Gemini-CLI n’est pas répertoriée dans la KEV, car Pillar Security l’a signalée dans le cadre d’un processus de divulgation responsable et le correctif était disponible avant toute exploitation. Cela n’exclut toutefois pas une inscription future, si une exploitation sur le terrain venait à être documentée.
Conseils de lecture de la rédaction
Plus depuis le réseau MBF Media
Source image de couverture : Pexels / panumas nikhomkhai (px:17489150)
Source image de couverture : Pexels / panumas nikhomkhai
