Mistral Vibe exécutait les hooks Git d'un dépôt avant les contrôles de confiance, permettant une RCE

Mistral a corrigé une faille d'exécution de code à distance dans son agent de développement Vibe, qui permettait à un dépôt malveillant d'exécuter des commandes shell sur la machine d'un développeur par le chemin même censé contenir ce dépôt. Le bug est référencé sous CVE-2026-93993. Il touche Mistral Vibe avant la version 2.25.5 et obtient 8,8 sur 10 (High) sur l'échelle CVSS 3.1. Mistral a publié la v2.25.5 le 18 septembre 2026, environ douze minutes après la clôture du ticket GitHub public décrivant la faille.

À lire aussi: Une faille sans clic laisse des plugins malveillants exécuter du code dans quatre grands agents de codage IA · Une faille d'authentification de Rejetto HFS trouvée par IA attire des tentatives d'exploitation.

Le code vulnérable exécutait les hooks Git d'un dépôt pendant la création d'un worktree, avant que l'agent ait décidé si ce dépôt pouvait être considéré comme fiable. Git exécute automatiquement un hook post-checkout à la création d'un worktree, si bien qu'un dépôt pouvait embarquer un hook lançant les commandes de l'attaquant avec les privilèges de l'utilisateur ayant démarré Vibe. L'utilisateur n'avait rien approuvé, car l'invite d'approbation que ces outils présentent comme leur frontière de sécurité n'apparaissait qu'après l'exécution de la charge malveillante.

L'ordre des opérations était la faille

Vibe est l'agent de développement open source de Mistral, natif du terminal, distribué comme paquet PyPI mistral-vibe. Il prend en charge une option --worktree, qui crée une copie de travail liée distincte afin que les modifications de l'agent ne touchent pas la copie principale de l'utilisateur. C'est précisément l'option que choisit un utilisateur prudent pour garder un dépôt non fiable à distance.

L'auteur du signalement à l'origine du ticket GitHub #996 a retracé le problème jusqu'au point d'entrée. Dans vibe/cli/entrypoint.py, l'agent appelle prepare_auto_worktree_session() ou prepare_worktree_session() lorsque --worktree est défini. Cet appel fait créer le worktree par Git et déclenche post-checkout. Le mécanisme de confiance est initialisé plus tard, dans init_harness_files_manager(). Il en résulte une fenêtre où du code contrôlé par le dépôt s'exécute avant qu'un quelconque contrôle de confiance existe pour l'arrêter.

Le ticket, intitulé « [Security] Remote Code Execution via worktree creation (git hook execution) », contenait un script Bash complet, copiable-collable, qui construit un dépôt malveillant : il initialise un dépôt, effectue un premier commit et installe un .git/hooks/post-checkout qui exécute id > /tmp/POC. Son auteur y donnait aussi directement son évaluation de gravité, en listant le vecteur CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H et le score de 8,8. Le ticket visait la v2.24.1.

Pour comprendre pourquoi cet ordre comptait, il faut distinguer les deux concepts Git en jeu. Un worktree est un second répertoire de travail lié au même dépôt ; le créer extrait des fichiers et déclenche donc les hooks liés au checkout. Un hook Git est un script stocké dans le dépôt sous .git/hooks/, et post-checkout s'exécute automatiquement après un checkout ou la création d'un worktree. Un hook est du contenu de dépôt ordinaire : un attaquant qui contrôle le dépôt contrôle le script. Aucune configuration ni approbation n'intervient normalement, puisque l'utilisateur a déjà demandé à Git d'extraire le code.

L'attaque exige tout de même qu'un utilisateur pointe l'agent vers un dépôt hostile, par exemple en le clonant ou en l'important puis en lançant Vibe dedans. Le vecteur CVSS le reflète : vecteur d'attaque réseau avec interaction utilisateur requise (UI:R). En pratique, la diffusion passe par de l'ingénierie sociale, un paquet typosquatté, ou n'importe quel dépôt qu'on demande à un développeur de « regarder rapidement ». C'est un seuil bien bas pour un outil conçu pour ouvrir du code inconnu et raisonner dessus.

Une preuve de concept publique restée en ligne plus de cinq semaines

La chronologie de la divulgation est inhabituelle. Selon l'API de GitHub, le ticket #996 a été créé le 11 août 2026 à 22 h 12 UTC par un utilisateur nommé therealcoiffeur, étiqueté security, bug, CLI et Security and Compliance, et assigné à un mainteneur. Il exposait la preuve de concept au grand jour et n'a reçu aucun commentaire. Il a été fermé le 18 septembre 2026 à 10 h 57 UTC. Mistral a publié la v2.25.5 à 11 h 09 UTC le même jour, environ douze minutes plus tard, depuis le commit c069ffa.

Le ticket est resté ouvert un peu plus de 37 jours. Le site d'actualité et d'analyse sécurité agenccy.ai retient le même écart de 37 jours et soutient que l'épisode a été mal interprété comme une divulgation coordonnée réussie, alors que le signalement n'était ni coordonné ni privé. Cette lecture relève de l'analyse et non d'une déclaration de l'éditeur, mais les horodatages sous-jacents sont publics.

Le correctif est arrivé sous la forme d'une seule ligne dans une longue liste « Fixed ». Les notes de la v2.25.5 indiquent : « La création ou le nettoyage d'un worktree n'exécute plus les hooks git du dépôt (comme post-checkout) ni sa commande fsmonitor. » Un point connexe de la même version ajoutait « des consignes de divulgation de vulnérabilités et des instructions de signalement privé dans SECURITY.md », ce qui signale en soi qu'un canal de signalement privé manquait pendant que le rapport restait public. Le correctif RCE n'est pas mis en avant comme une correction de sécurité, et au 21 septembre Mistral n'avait publié aucun avis distinct nommant la CVE, si bien qu'un utilisateur parcourant le changelog n'y trouverait aucune raison évidente de mettre à jour en urgence.

Le mode de divulgation soulève un arbitrage classique. Un signalement public et non coordonné, assorti d'un exploit fonctionnel, peut forcer la main d'un éditeur et alerter les défenseurs, mais il fournit aussi aux attaquants un outil prêt à l'emploi et laisse les utilisateurs exposés tant que le rapport est ignoré. Ici, la preuve de concept était bénigne, écrivant la sortie de id dans un fichier, mais la même technique permet n'importe quelle commande. Le silence d'un mainteneur sur un problème de sécurité public pendant plus de cinq semaines est l'élément qui intéressera les autres projets diffusant des outils agentiques.

D'où vient le 8,8

La CVE a été attribuée par VulnCheck, et non par Mistral, et l'avis de VulnCheck crédite Mathieu Farrell comme découvreur. Le ticket public a été ouvert par therealcoiffeur ; le dossier public ne dit pas d'emblée si les deux sont la même personne, il faut donc traiter le crédit et le signalement comme deux faits distincts.

Le dossier CVE, publié sur CVE.org le 19 septembre à 22 h 58 UTC et sur le NVD à 23 h 17 UTC, comporte deux scores. Le score de base CVSS 3.1 est de 8,8 (High) avec le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, et le score de base CVSS 4.0 est de 8,6 (High). La faiblesse est classée CWE-829, « Inclusion de fonctionnalités provenant d'une sphère de contrôle non fiable ». Le paquet concerné est pkg:pypi/mistral-vibe, versions 0 jusqu'à 2.25.5 exclue. Le NVD répertoriait le dossier avec le statut « Received » au 21 septembre, signifiant qu'il n'avait pas encore fait l'objet de son propre enrichissement.

Les deux scores viennent de VulnCheck, et selon l'analyse d'agenccy.ai, le 8,8 correspond au vecteur que le rapporteur a écrit dans le ticket public, repris dans la CVE par le CNA. Aucune gravité fournie par l'éditeur n'apparaît dans le dossier. Cela compte pour la façon de lire ce chiffre : c'est une évaluation tierce crédible, pas celle de Mistral, et il faut la traiter comme telle.

Pourquoi cela se répète, et comment réagir

Les agents de développement exécutent par conception du contenu de dépôt non fiable. Ils lisent des fichiers, installent des dépendances, lancent des commandes de build et de test, et touchent souvent à Git. La frontière entre « le code que l'on inspecte » et « le code que l'on exécute » constitue donc tout le modèle de sécurité, et il est facile de se tromper d'ordre. Toute étape qui amène Git, un gestionnaire de paquets ou un script de build à s'exécuter avant la décision de confiance est un chemin d'exécution potentiel avant approbation. Les hooks Git en sont un exemple classique, car ils s'exécutent automatiquement et sont stockés dans le dépôt lui-même.

Vibe n'est pas le seul agent concerné. Une autre faille divulguée en septembre 2026, référencée Plugin4Shell, permettait à un plugin de confiance d'exécuter du code d'attaquant via les systèmes de plugins de Claude Code, Codex d'OpenAI, GitHub Copilot et Gemini CLI de Google. Le mécanisme reposait sur un contournement de l'épinglage SHA plutôt que sur un hook Git, mais la question de fond est la même pour tout agent qui ouvre du code tiers : qu'est-ce qui s'exécute avant la décision de confiance, et qui le contrôle ? Les agents qui gèrent Git eux-mêmes héritent de la surface d'exécution de Git, hooks, filtres, pilotes de diff externes et commandes de surveillance de fichiers compris. Les notes de la v2.25.5 montrent que Mistral a dû désactiver plusieurs de ces chemins, dont le hook de checkout, en corrigeant la gestion des worktrees.

La réponse pour les utilisateurs est simple. Mettez Vibe à jour vers la version 2.25.5 ou ultérieure, qui empêche la création et le nettoyage d'un worktree d'exécuter les hooks du dépôt. Ne considérez l'invite de confiance comme utile que si elle précède l'exécution, et non seulement si elle la suit. Restez prudent avec les dépôts venus de sources que vous ne contrôlez pas, même sur les versions corrigées, car les nouveaux bugs d'ordre d'opérations sont un schéma récurrent et non un cas isolé. Quand le flux de travail le permet, exécutez l'agent dans un conteneur ou une machine virtuelle jetable aux identifiants limités, afin qu'un hook qui se déclenche ne puisse pas atteindre les vraies clés SSH, les jetons cloud ou l'arborescence source du développeur. Les équipes peuvent aussi définir core.hooksPath vers un répertoire vide hors du dépôt comme mesure de défense en profondeur, même s'il s'agit d'une atténuation de cette classe de bug, pas d'un substitut à la mise à jour. Pour les mainteneurs, la leçon est d'examiner ce que fait un agent de développement au démarrage, avant toute étape d'approbation, et pas seulement à l'intérieur d'une session.

À surveiller désormais : si Mistral publie son propre avis avec un score de gravité d'éditeur, si la pull request de correctif #1032, encore ouverte, intitulée « fix(git): disable repository hooks during worktree creation », est fusionnée ou supplantée par le commit de version, et si les autres éditeurs d'agents auditent leurs propres chemins de hooks et de checkout. Le crédit et la ligne du changelog sont déjà publics. La question ouverte est la vitesse à laquelle le reste de la catégorie vérifie la même séquence.

Couverture : le cofondateur et PDG de Mistral AI, Arthur Mensch, à Techarena 2026, par Jan2342342423 (CC0 1.0) via Wikimedia Commons, recadrée en 16:9.