Il a dit à Claude Code « il paraît qu'il y a une 0-day dans Vim. Trouve là ». Et Claude a sorti une faille réelle et inconnue jusqu'alors. Rapidement patchée. Il suffisait d'ouvrir un fichier markdown contenant certaines commandes pour que le code arbitraire soit exécuté. Les versions concernées sont Vim > 9.1.1391 && Vim < 9.2.0272 donc la vulnérabilité est là depuis mai 2025. J'ai testé sur ma distro et le PoC fonctionne.
Puis ils ont demandé la même chose en fournissant le code d'Emacs et résultat : "GNU Emacs: Multiple Remote Code Execution Vectors on File Open". Sauf que là les mainteneurs refusent de corriger parce qu'ils attribuent le comportement à git. Je n'ai pas fouillé plus avant. Explications en français : https://cyberveille.ch/posts/2026-03-31-des-rce-decouvertes-dans-vim-et-gnu-emacs-via-claude-ia-ouverture-de-fichier-suffisante/
Claude a trouvé les failles mais l'histoire ne dit pas si c'est lui qui les a précédemment créées vu qu'un fork de Vim est né à cause de l'utilisation de l'IA par certains dev ! (Humour, rien dans la faille du jour ne laisse penser que ça viendrait de l'IA et le dev à qui on reprochait l'utilisation de LLM n'apparaît pas dans le commit qui a créé la faille. Une bonne vieille erreur humaine est probable.)
# Vraiment un problème ?
Posté par rick . Évalué à 1 (+2/-1).
J'ai l'impression qu'on fait beaucoup de bruits pour pas grand chose. En effet, il y avait un soucis et ça a été patché, mais ça semble quand même venir d'une fonctionnalité de VIm: la possibilité de mettre des commandes pour configurer l'éditeur directement dans le fichier.
Est-ce que c'est vraiment une faille nouvelle, ou plutôt une RCE as a feature qui était déjà là depuis longtemps ?
Du côté d'Emacs, quand on regarde la cascade d'évènements qui mène à ça, je rejoins l'analyse des mainteneurs (vous pouvez l'exécuter avec la commande git ls-files… ah non, avec toutes les commandes git). Mais pourquoi ? Parce que Git a une fonctionnalité qui permet de définir un script pour un hook. Et c'est ce script qui est exécuté. Or, il s'agit d'un hook qui ne se trouve qu'en local, donc s'il se trouve sur votre PC, il y a d'autres soucis à se faire.
Ça me rappelle le fuzzing ce genre de tickets, avec une bibliothèque d'analyse d'images qui s'est faite fuzzer et le mainteneur a tout rejeté parce que "bah oui, ça crash sur une image qui n'est pas valide, vous vous attendiez à quoi ?". (si une bonne âme a la source, je ne m'en souviens plus…)
Tout ça pour dire que ce genre de failles, je les trouve un peu ridicule quand on creuse un peu… À ça de se demander si les chercheurs ont vraiment creusé le problème (du moins pour Emacs).
[^] # Re: Vraiment un problème ?
Posté par Faya . Évalué à 3 (+1/-0).
Ça n'est pas supposé se produire avec n'importe quel fichier, et "configurer l'éditeur" ne veut pas dire "exécuter n'importe quelle commande avec les droits de l'utilisateur". Pour Emacs je ne sais pas, je ne l'utilise pas donc je n'ai pas testé. Mais pour Vim que j'utilise quotidiennement le problème me paraît important (et de fait ils l'ont classé en
Severity: High). Je t'envoie un simple fichier markdown qui contient une commande pour supprimer ton home ou m'envoyer tes cookies de session, tu l'ouvres avec Vim et paf. Ça n'est pas anodin.[^] # Re: Vraiment un problème ?
Posté par rick . Évalué à 2 (+2/-0).
Je crois que si justement, ils utilisent des commandes qu'on peut exécuter à l'ouverture du fichier pour pouvoir le configurer d'une certaine manière sans passer par le vimrc. En relisant par contre, je n'avais pas vu la partie sandbox de vim (j'ignorais qu'il faisait ça dans certains cas).
Je suis d'accord que ce n'est pas anodin, mon propos était plutôt sur le fait que ça vient d'une fonctionnalité (en sandbox, je viens de le découvrir). J'ai trouvé que c'était un peu comme accuser la commande :r de pouvoir faire du RCE. Je me corrige, ce n'est pas le cas, vu qu'il y a la sandbox (même si je ne sais pas trop comment elle protège de ça, quelles commandes elle restreint, etc.).
[^] # Re: Vraiment un problème ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Oui, il y a un bac à sable pour des trucs évalués, et ici le truc dépend de
modelineexprde ce que je comprends.Il y a plein d’options qui ne sont pas autorisées dans les modelines mais je pense perso qu’on devrait encore plus restreindre la liste ; j’en parle dans un prochain journal.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# La faille dans vim
Posté par benoar . Évalué à 3 (+1/-0).
La faille a été ajoutée par un commit de l’an dernier ajoutant une feature « tabpanel » https://github.com/vim/vim/commit/be5bd4d6292fddcc103091407792730aaa48cc48
La PR : https://github.com/vim/vim/pull/17263
Perso je trouve ce commit plutôt moche, mais je n’ai pas d’habitude de lire les sources de vim. D’autres dans la PR disent que ça n’a pas l’air d’avoir été suffisamment retravaillé avant inclusion.
Je serai méchant je dirai que vu l’étendue et la taille du patch (ça touche au nombre de colonnes en largeurs, qu’on retrouve partout dans le code avec une variables Columns, maintenant remplacée par une macro moche COLUMNS_WITHOUT_TPL(), qui est une soustraction, alors que les calculs sont explicites partout ailleurs), ça serait l’idéal pour y planquer une faille.
Enfin, je pense surtout que ça a été fait assisté d’un LLM (hypothèse gratuite) parce que c’est moche, et que c’est ironique qu’on utilise des LLM pour dénicher des failles introduites par des LLM…
[^] # Re: La faille dans vim
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Bien que je lise tous les journaux de changements, je n’avais pas tilté sur ce truc. Comme écrit Theo Park, à juste titre (en ce qui me concerne)
Pour la beauté du code, on voit en effet que ça ne porte pas la touche (et la longue expérience) de Bram. RIP champion.
Pour alimenter la supputation, peut-on dire que le bogue est un llm-egg ? :D
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# C’est une feature pas un bug
Posté par mart-e (site web personnel) . Évalué à 1 (+1/-0).
Je suis assez d’accord avec les mainteneurs d’emacs, c’est un soucis indépendant de l’éditeur si on télécharge un répo git (une archive contenant un dossier .git), on s’expose à des commandes arbitraires.
git config core.fsmonitorpermet de donner un script à exécuter lorsque l’on exécutegit status.Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.