**Google** a corrigé une faille de sécurité de gravité maximale dans **Gemini CLI** – le package npm `@google/gemini-cli` et le workflow **GitHub Actions** `google-github-actions/run-gemini-cli` – qui aurait pu permettre à des attaquants d'exécuter des commandes arbitraires sur les systèmes hôtes. **Exécution de code à distance par Gemini CLI** "La vulnérabilité permettait à un attaquant externe non privilégié de forcer le chargement de son propre contenu malveillant en tant que configuration **Gemini**", a déclaré **Novee Security** dans un rapport publié mercredi. "Cela déclenchait l'exécution de commandes directement sur le système hôte, contournant la sécurité avant même que le sandbox de l'agent ne soit initialisé." La faille, qui ne possède pas d'identifiant **CVE**, a un score **CVSS** de 10.0. Elle affecte les versions suivantes : * `@google/gemini-cli < 0.39.1` * `@google/gemini-cli < 0.40.0-preview.3` * `google-github-actions/run-gemini-cli < 0.1.22` Dans son avis publié la semaine dernière, **Google** a indiqué que l'impact était limité aux workflows utilisant **Gemini CLI** en mode headless, ajoutant que toute utilisation de l'outil en mode headless sans confiance dans le dossier nécessiterait une révision manuelle pour configurer ce mécanisme de confiance. "Dans les versions précédentes, **Gemini CLI** fonctionnant dans des environnements CI (mode headless) faisait automatiquement confiance aux dossiers de l'espace de travail pour charger la configuration et les variables d'environnement", a-t-il déclaré. Cette confiance automatique dans le dossier de l'espace de travail actuel signifiait que l'outil pouvait charger n'importe quelle configuration d'agent trouvée sans révision, sandboxing ou consentement explicite de l'utilisateur. Un attaquant pouvait exploiter ce comportement en plaçant une configuration spécialement conçue qui pourrait ouvrir la voie à l'exécution de code sur l'hôte exécutant l'agent, transformant ainsi efficacement les pipelines CI/CD en chemins d'attaque de la chaîne d'approvisionnement. La mise à jour résout le problème en exigeant que les dossiers soient explicitement approuvés avant que les fichiers de configuration ne puissent être accessibles. À cette fin, les utilisateurs sont invités à examiner leurs workflows et à adopter l'une des deux approches suivantes : * Si le workflow s'exécute sur des entrées de confiance (par exemple, examen des pull requests de collaborateurs de confiance), définissez `GEMINI_TRUST_WORKSPACE: 'true'` dans le workflow. * Si le workflow s'exécute sur des entrées non fiables, consultez les instructions de **Google** dans `google-github-actions/run-gemini-cli` pour renforcer le workflow contre le contenu malveillant, et définissez la variable d'environnement. Le géant de la technologie a également noté qu'il prenait des mesures pour renforcer la liste blanche des outils lorsque **Gemini CLI** est configuré pour s'exécuter en mode `--yolo` afin d'éviter les scénarios où des entrées non fiables (par exemple, des problèmes **GitHub** soumis par les utilisateurs) pourraient conduire à une exécution de code à distance via l'injection de prompts en profitant du fait que le mode d'approbation automatique ignorerait toute liste blanche dans `~/.gemini/settings.json` et exécuterait tous les appels d'outils automatiquement (y compris "run_shell_command") sans nécessiter de confirmation utilisateur. "Dans la version 0.39.1, le moteur de politique de **Gemini CLI** évalue désormais la liste blanche des outils en mode `--yolo`, ce qui est utile pour les workflows CI qui autorisent quelques commandes sûres à s'exécuter lors du traitement d'entrées non fiables", a déclaré **Google**. "En conséquence, certains workflows qui dépendaient auparavant de ce comportement peuvent échouer silencieusement à moins que les listes blanches d'outils ne soient modifiées pour s'adapter à la tâche." ### Un bug dans **Cursor** conduit à l'exécution de code  La divulgation intervient alors que **Novee Security** a également mis en évidence une vulnérabilité de haute gravité dans l'outil de développement basé sur l'IA **Cursor** avant la version 2.5 (**CVE-2026-26268**, score **CVSS** : 8.1) qui pourrait également conduire à une exécution de code arbitraire par le biais d'une injection de prompt. **Cursor**, dans une alerte publiée en février 2026, l'a décrit comme un cas d'évasion de sandbox via des configurations `.git`, permettant à un agent malveillant de configurer un dépôt nu (`.git`) avec un [hook **Git**](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) malveillant qui est automatiquement déclenché chaque fois qu'une opération de commit s'exécute dans le contexte du dépôt intégré sans nécessiter d'interaction utilisateur. Le résultat final est une exécution de code arbitraire approuvée automatiquement sur la machine de la victime via la séquence d'actions suivante : * L'utilisateur clone un dépôt **GitHub** public avec le dépôt nu intégré contenant un hook post-checkout malveillant * L'utilisateur ouvre le dépôt dans **CursorIDE** * L'utilisateur pose une question anodine comme "expliquer le codebase" * L'agent **Cursor** analyse le fichier AGENTS.md qui lui demande de naviguer vers le dépôt nu et effectue un "git checkout" de la branche master * Le hook post-checkout à l'intérieur du dépôt nu est déclenché, conduisant à l'exécution de code. "La cause profonde n'est pas une faille dans la logique principale du produit **Cursor**, mais plutôt une conséquence d'une interaction de fonctionnalités dans **Git**, une qui devient exploitable dès qu'un agent IA commence à exécuter de manière autonome des opérations **Git** dans un dépôt qu'il ne contrôle pas", a déclaré le chercheur en sécurité Assaf Levkovich. "Lorsque l'agent exécute `git checkout` dans le cadre de la réponse à une demande de routine, il ne fait rien que l'utilisateur n'ait pas implicitement autorisé. Mais ni l'utilisateur ni l'agent n'ont de visibilité sur ce que les **Règles Cursor** du dépôt ont mis en mouvement. Un hook pre-commit malveillant intégré dans un dépôt nu imbriqué s'exécute silencieusement, en dehors de la chaîne de raisonnement de l'agent et en dehors du champ de vision de l'utilisateur." ### **CursorJacking** : Vol de clés API Les découvertes coïncident également avec la découverte d'une autre vulnérabilité de contrôle d'accès de haute gravité dans l'IDE (score **CVSS** : 8.2) qui pourrait permettre à toute extension installée d'accéder aux clés API et aux identifiants sensibles stockés localement dans une base de données **SQLite**, permettant ainsi la prise de contrôle de compte, l'exposition de données et des pertes financières résultant d'une utilisation non autorisée de l'API. Le problème, baptisé **CursorJacking** par **LayerX**, reste non corrigé. "**Cursor** n'applique pas de limites de contrôle d'accès entre les extensions et cette base de données", a déclaré Roy Paz, chercheur chez **LayerX**. "L'exploitation de cette vulnérabilité peut entraîner l'exposition de jetons de session et de clés API, un accès non autorisé aux services backend de **Cursor**, et le vol de données via l'usurpation d'identité d'utilisateur." **Cursor** a maintenu que l'accès est limité à la machine locale où l'utilisateur a déjà installé et accordé des autorisations à l'extension, ce qui signifie que toute extension malveillante ayant accès au système de fichiers local pourrait potentiellement extraire des informations précieuses de divers magasins de données d'applications. Pour contrer la menace, il est essentiel que les utilisateurs s'en tiennent au téléchargement d'extensions de confiance.