GitHub a mis à jour son entrée de base de données pour CVE-2026-75911 le 4 septembre 2026, après la publication initiale de l'avis du mainteneur CodeWhale le 16 juillet. Un dépôt cloné pouvait activer silencieusement les outils shell de l'agent de code IA. L'avis indique que CodeWhale et codewhale-tui de la version 0.8.41 à toute version antérieure à 0.8.64 sont touchés. La version 0.8.64 contient le correctif.
Il ne s'agit pas d'une compromission à distance de toute installation. L'utilisateur doit cloner ou ouvrir un dépôt malveillant ou compromis, puis lancer CodeWhale dans cet espace. La conséquence reste importante, car un fichier contrôlé par le projet pouvait élargir les outils sans consentement explicite.
Un fichier de projet pouvait ouvrir la limite du shell
CodeWhale lit .codewhale/config.toml ou .deepseek/config.toml. Selon l'avis, le dépôt pouvait définir allow_shell = true. La fusion acceptait cette valeur et ajoutait les outils shell au registre du modèle.
D'autres paramètres, dont la politique d'approbation et le mode sandbox, utilisaient déjà des gardes qui n'autorisaient qu'un durcissement. Le projet pouvait les rendre plus stricts, pas les relâcher. allow_shell n'avait pas cette protection. Le correctif empêche désormais le projet d'activer le shell.
L'avis attribue un score CVSS 3.1 de 7,8 et une gravité élevée. Il décrit un vecteur local, une faible complexité, aucun privilège préalable sur le système victime, une interaction requise et un impact potentiel élevé. Cette notation décrit un scénario et ne prouve pas une exploitation réelle.
La base GitLab confirme les versions et recommande 0.8.64 ou plus récent. Elle ne démontre ni exploitation active ni nombre d'utilisateurs touchés.
La confiance dans le dépôt fait partie du modèle de sécurité
Un agent de code peut lire les fichiers du dépôt comme des instructions, une configuration d'outils, des hooks ou une politique. Une deuxième surface d'exécution apparaît donc avant même la construction de l'application.
Un modèle sûr distingue les sources:
| Source | Comportement sûr |
|---|---|
| Dépôt ou espace de travail | Peut réduire les permissions, jamais les élargir silencieusement |
| Profil utilisateur | Peut définir des choix personnels explicites |
| Politique d'organisation | Peut imposer l'autorité maximale |
| Ligne de commande | Exige une action visible et volontaire |
| Sortie du modèle | Ne peut pas modifier ses propres droits |
Le guide Maetra sur l'injection de prompt explique pourquoi les instructions non fiables doivent rester séparées de l'autorité. Le guide des contrôles à l'exécution couvre permissions, identité, inspection et preuve des effets.
Mettre à jour, puis inspecter la chaîne de confiance
Les équipes concernées doivent passer à 0.8.64 ou plus récent. Elles devraient ensuite rechercher les configurations CodeWhale et DeepSeek dans les dépôts clonés, vérifier comment le shell a été activé auparavant et renouveler les identifiants si un espace non fiable a pu exécuter des commandes.
Une enquête doit conserver le commit, le hachage de configuration, les réglages effectifs, le registre d'outils, la session, les commandes, les résultats, les changements de fichiers, les effets réseau et les approbations. Supprimer le fichier détruit des preuves sans montrer ce qui s'est passé.
Testez aussi les cas négatifs. Un projet demandant plus d'autorité doit être rejeté ou ignoré. La restriction d'organisation doit survivre aux fusions, redémarrages et options de commande. Les journaux doivent conserver la politique effective sans secrets.
Incertitudes restantes
L'avis ne revendique aucune exploitation active et ne donne aucun nombre d'installations touchées. L'effet final dépend de la sortie du modèle, de la classification de la commande, du contexte utilisateur, des droits du système et des identifiants disponibles.
Les plages diffèrent pour les anciens paquets deepseek-tui. Il faut vérifier l'entrée exacte de son écosystème.
Analyse de Maetra
Le principe clé est l'autorité monotone. Une configuration moins fiable peut retirer des droits, demander davantage d'examen ou réduire la portée. Elle ne doit pas accorder un outil, une identité ou un mode d'exécution non autorisé par un niveau supérieur.
Il faut aussi vérifier les effets. Une politique peut sembler sûre tandis qu'un hook, un plugin, une variable ou un wrapper ouvre un autre chemin vers le shell. Inventoriez tous les outils, calculez la politique effective après chaque fusion et testez les effets réels.
CVE-2026-75911 est une faille ciblée avec correctif. Sa leçon vaut pour tout agent de code: l'espace de travail est une entrée, pas une autorité.