Une simple invite a envoyé Claude Code dans une mission qui a révélé des vulnérabilités de sécurité majeures dans les éditeurs de texte populaires, puis a suggéré des moyens de les exploiter.
Les développeurs peuvent passer des journées entières à utiliser des outils de fuzzing pour détecter les failles de sécurité du code. Alternativement, ils peuvent simplement demander à un LLM de faire le travail à leur place en quelques secondes.
Le problème : les LLM évoluent si rapidement que cette commodité peut comporter des dangers cachés.
Le dernier exemple est celui du chercheur Hung Nguyen de la société Calif Red Teaming, qui, avec de simples instructions sur Claude Code d’Anthropic, a pu découvrir des exploits de code à distance (RCE) Zero Day dans le code source de deux des éditeurs de texte pour développeurs les plus populaires, Vim et GNU Emacs.
Nguyen a commencé avec Vim. « Quelqu’un m’a dit qu’il y avait un RCE 0-jour à l’ouverture d’un dossier. Trouvez-le », a-t-il demandé à Claude Code.
En deux minutes, Claude Code avait découvert la faille : des contrôles de sécurité critiques manquants ( et ) dans la barre latérale du panneau d’onglets introduit en 2025, et un contrôle de sécurité manquant dans la fonction.
Claude Code a ensuite utilement tenté de trouver des moyens d’exploiter la vulnérabilité, suggérant finalement une tactique permettant de contourner le bac à sable Vim en persuadant une cible d’ouvrir un fichier malveillant. Il est passé de l’invite à l’exploit de preuve de concept (PoC) en quelques minutes.
« Un attaquant capable de transmettre un fichier contrefait à une victime parvient à exécuter des commandes arbitraires avec les privilèges de l’utilisateur exécutant Vim », ont noté les responsables de Vim dans leur avis de sécurité. « L’attaque nécessite simplement que la victime ouvre le fichier ; aucune autre interaction n’est nécessaire. »
GNU Emacs « pour toujours »
Surpris, Nguyen a alors suggéré en plaisantant à Claude Code de trouver le même type de faille dans un deuxième éditeur de texte, GNU Emacs.
Claude Code s’y est rendu en trouvant une vulnérabilité zero-day, remontant à 2018, dans la façon dont le programme interagit avec le système de contrôle de version Git qui permettrait d’exécuter du code malveillant simplement en ouvrant un fichier.
« L’ouverture d’un fichier dans GNU Emacs peut déclencher l’exécution de code arbitraire via le contrôle de version (git), la plupart ne nécessitant aucune interaction de l’utilisateur au-delà de l’ouverture du fichier lui-même. La découverte la plus grave ne nécessite aucune variable locale du fichier – il suffit d’ouvrir n’importe quel fichier dans un répertoire contenant une exécution contrefaite de commandes contrôlées par l’attaquant », a-t-il écrit.
Un fixe, un pas
Lorsqu’ils ont été avertis, les responsables de Vim ont rapidement résolu leur problème, identifié comme CVE-2026-34714 avec un score CVSS de 9,2, dans la version 9.2.0272.
Malheureusement, remédier à la vulnérabilité GNU Emacs, qui est actuellement sans identifiant CVE, n’est pas aussi simple. Ses responsables pensent qu’il s’agit d’un problème avec Git et ont refusé de résoudre le problème ; dans son message, Nguyen suggère des atténuations manuelles. Les versions vulnérables sont 30.2 (version stable) et 31.0.50 (développement).
Code vulnérable
Que nous apprend la découverte de ces failles ? De toute évidence, un grand nombre d’anciennes bases de code sont potentiellement vulnérables à la puissance des outils d’IA tels que Claude Code. Ce n’est pas parce qu’une faiblesse n’a pas été remarquée depuis des années qu’elle restera longtemps cachée à l’ère de l’IA.
Il s’agit potentiellement d’un grand changement, même s’il n’a pas déjà été signalé par Anthropic lui-même. En février, la société a révélé que son modèle Opus 4.6 avait été utilisé pour identifier 500 failles de sécurité de haute gravité.
« Les modèles de langage d’IA sont déjà capables d’identifier de nouvelles vulnérabilités et pourraient bientôt dépasser la vitesse et l’ampleur des chercheurs humains, même experts », avait-il déclaré à l’époque.
La plateforme est suffisamment puissante pour qu’une version entreprise dotée des mêmes capacités, Claude Code Security, ait même affecté négativement le sentiment du marché boursier à l’égard de plusieurs sociétés de cybersécurité traditionnelles lors de son lancement.
Un deuxième problème est que les LLM sont désormais capables de détecter, d’itérer et de créer des PoC pour les vulnérabilités d’une manière que les développeurs doivent encore accepter. Parallèlement, le potentiel d’utilisation malveillante est difficile à ignorer.
« Comment pouvons-nous, nous, chasseurs de bogues professionnels, comprendre cela ? » » a demandé Nguyen. « Cela ressemble au début des années 2000. À l’époque, un enfant pouvait tout pirater, avec l’injection SQL. Maintenant (ils le peuvent) avec Claude. »
