Vulnérabilité critique dans Gemini CLI et GitHub Actions expose la chaîne d'approvisionnement CI à l'exécution de code à distance

La vulnérabilité critique corrigée par Google dans Gemini CLI (paquet npm @ google / gemini-cli) et dans le flux de travail des actions GitHub Google-github-actions / run-gemini-cli qui a permis d'exécuter des commandes arbitraires dans le système hôte lorsque l'outil a été utilisé en mode sans tête dans CI. La racine du problème était une confiance implicite dans le dossier de travail: dans les versions touchées, les paramètres chargés CLI et les variables d'environnement de .gemini/ sans validation lors de l'exécution dans des environnements automatisés, qui ont ouvert la porte vers laquelle le contenu malveillant planté par un attaquant a été traité comme une configuration légitime et a déclenché l'exécution de code à distance.

Le défaut, qualifié avec une sévérité maximale (CVSS 10.0) par des chercheurs externes, illustre comment un raccourci d'utilisation dans les pipelines automatisés devient un vecteur d'attaque de chaîne d'approvisionnement : l'analyse des demandes de traction, des fourchettes ou du contenu de tiers peut devenir des pièges si un outil suppose que l'espace de travail est fiable. Google a atténué le risque en forçant maintenant les dossiers à être explicitement marqués comme fiables avant de lire les fichiers de configuration et en proposant des variables d'environnement et des paramètres spécifiques pour les workflows, ainsi que durcissant les vérifications licencielles lorsque le CLI est exécuté avec --yolo.

Si vous utilisez Gemini CLI dans GitHub Actions, l'action immédiate est de mettre à jour les versions corrigées: install @ google / gemini-cli dans des versions égales ou supérieures à celles qui corrigent la défaillance (les versions vulnérables sont celles indiquées par le fournisseur) et mises à jour Google-github-actions / run-gemini-cli à la version 0.1.22 ou ultérieure. Consultez la page du dépôt pour obtenir les versions et le guide de configuration : Google-github-actions / run-gemini-cli et paquet npm @ google / gemini-cli en npm.

Il ne suffit pas de mettre à jour: vos workflows. Si votre flux ne traite que des entrées de collaborateurs de confiance, vous pouvez choisir d'établir GEMINI _ TRUST _ WORKSPACE: 'true' dans l'environnement de travail, mais ne le faites pas si vous acceptez des contributions de tiers ou de fourchettes. Pour les entrées peu fiables, suivez le guide officiel de durcissement et traitez l'espace de travail comme un hôte : montez des coureurs éphémères, limitez les permissions d'action avec le minimum nécessaire, désactivez l'accès inutile aux secrets et utilisez des règles d'autorisation strictes pour toute fonctionnalité qui exécute des commandes ou des processus.

En outre, Google a modifié le comportement de --yolo (mode auto-approbation) de sorte que la politique de la liste d'outils est également évaluée dans ce mode; qui empêche les appels à des fonctions dangereuses telles que l'exécution _ shell _ commande de fonctionner sans restrictions. Cependant, le changement peut causer des défaillances silencieuses dans les workflows précédents, il est donc approprié d'examiner et d'ajuster les licenselists pour maintenir la fonctionnalité requise sans sacrifier la sécurité.

Le cas de Gemini doit être lu conjointement avec d'autres vulnérabilités récentes dans les outils pilotés par l'IV. Des chercheurs ont également décrit un vecteur IDE Cursor qui a permis l'exécution arbitraire par des techniques d'injection rapide malveillantes et des crochets Git dans des dépôts « embeded » (.git), en plus d'une défaillance de contrôle d'accès qui a permis aux extensions locales de lire les identifiants stockés dans des bases SQLite. Ces incidents renforcent une tendance : les agents indépendants qui effectuent Les opérations ou systèmes Git qui accordent des privilèges d'extension peuvent convertir des fonctionnalités légitimes en vecteurs d'attaque lorsqu'ils sont combinés avec des dépôts malveillants ou des paquets.

Que faire face à ces menaces : d'abord, appliquer immédiatement les correctifs et abonnez-vous aux avis de sécurité des projets que vous utilisez. Deuxièmement, il réduit la surface d'attaque dans CI: execteurs éphémères, séparation d'emploi, examen manuel des PR de Forks avant d'exécuter des workflows qui traitent le contenu et la numérisation automatisée des artefacts entrants. GitHub maintient des recommandations utiles sur le durcissement des mesures à suivre: Harcèlement de sécurité pour les actions de GitHub.

Pour les outils de développement locaux comme Cursor, la pratique minimale n'est pas d'ouvrir des dépôts inconnus dans des environnements avec des agents qui agissent automatiquement, d'éviter d'installer des extensions source peu fiables et de limiter l'accès des extensions au système de fichiers. Si vous travaillez déjà avec des secrets locaux ou des clés API, vous brisez les identifiants exposés et utilisez des gestionnaires de comptes secrets et de services avec des privilèges limités pour l'IC au lieu de jetons personnels.

Enfin, il adopte des défenses en profondeur : il intègre l'analyse statique et la numérisation d'unité dans votre pipeline, permet des politiques de sécurité qui inspectent les fichiers de configuration (y compris les fichiers dot tels que .git et .gemini), et établit des procédures d'approbation humaine quand un agent va exécuter des changements de système. La commodité des agents d'IV et des outils automatisés ne devrait pas remplacer les contrôles d'isolement et d'examen de base; la sécurité défensive demeure la meilleure protection contre les explosifs cachés dans la chaîne d'approvisionnement.