Le blogue techno
Chroniques de l’ère numérique
Chroniques de l’ère numérique : expertise et veille en cybersécurité
Recherche & expertise
«Grep your 0days»
Temps de lecture :
12 minute(s)
-
30 avril 2026
IA, LLM et recherche de vulnérabilités
Il fut un temps, dans le domaine de la recherche de vulnérabilités, où il n’existait essentiellement que deux méthodes pour découvrir des failles : l’audit de code et le fuzzing.
L’audit de code est une tâche exigeante qui consiste à lire manuellement du code afin d’identifier des patterns vulnérables, puis à déterminer s’ils sont atteignables et exploitables. Historiquement, ce processus n’était réellement viable que si l’auditeur possédait une solide connaissance du type de logiciel ciblé, du langage de programmation utilisé et, bien sûr, des bases en ingénierie logicielle. Cette tâche peut toutefois devenir extrêmement complexe lorsqu’il s’agit de logiciels massifs comptant des millions de lignes de code, comme les kernels de systèmes d’exploitation ou les navigateurs Web. Même les mainteneurs de ces codebases ne comprennent pas toujours l’entièreté du logiciel. Par conséquent, les chercheurs ciblent souvent une surface d’attaque précise afin d’augmenter leurs chances de succès.
Le fuzzing, de son côté, représentait le sommet de la recherche automatisée de vulnérabilités : il consiste à injecter des entrées aléatoires, mutées de façon répétée jusqu’à atteindre un chemin de code vulnérable et provoquer un crash. Les fuzzers guidés par la couverture, comme AFL++ et Fuzzilli, se sont imposés comme des standards de l’industrie. Cette méthode exige certaines connaissances de base pour configurer les fuzzers, choisir la surface d’attaque à cibler, puis laisser la machine faire le travail lourd.
Ces deux méthodes constituaient le socle de la recherche de zero-days. Toutes deux nécessitaient un haut niveau de compétence, une connaissance technique approfondie, des outils personnalisés et une part de chance. Heureusement, un nouveau joueur est arrivé dans le paysage : la recherche automatisée de vulnérabilités par l’IA. Les grands modèles de langage, ou Large Language Models (LLM), démontrent de plus en plus leur valeur dans les processus de bug hunting et d’exploitation, qu’il s’agisse de vieux bugs de kernel découverts des décennies plus tard, de zero-days modernes sur Windows ou de failles d’exécution de code à distance, ou remote code execution (RCE), dans les navigateurs. Comme il ne manque pas de matériel public lié aux zero-days pour entraîner les modèles, il est raisonnable de supposer que tout LLM moderne a été exposé à davantage de code vulnérable qu’un chercheur individuel pourrait en rencontrer au cours de toute sa carrière.
Le savoir-faire que les hackers ont mis des années à perfectionner est en train d’être réduit à un simple prompt et à un solde de tokens respectable. Ce changement pourrait rendre la découverte avancée de vulnérabilités plus accessible à toute personne ayant accès à cette technologie, en facilitant l’identification de failles critiques dans des logiciels majeurs. En parallèle, les acteurs malveillants risquent fort d’exploiter ces capacités pour industrialiser leurs efforts de bug hunting et d’exploitation, particulièrement les groupes soutenus par des États, qui disposent de budgets importants et de personnel hautement qualifié.
Plusieurs se demandent déjà si l’IA est devenue un hacker plus efficace que l’humain.
Pour le vérifier, j’ai mené une petite expérience. Il y a quelques semaines, j’ai lu un article expliquant comment Claude avait trouvé une zero-day dans radare2. Le chercheur l’avait orienté vers la codebase et, après quelques prompts, Claude avait généré une preuve de concept, ou proof of concept (PoC), fonctionnelle d’injection de commande. J’ai trouvé cela très impressionnant, surtout considérant que les prompts étaient très directs. Fait intéressant toutefois, Claude n’a pas réussi à trouver de problèmes de corruption mémoire.
« Claude a eu de la difficulté à prouver, et encore plus à exploiter, les vulnérabilités de corruption mémoire. Il semblait toutefois progresser sur un problème de fuite de tas, ou heap leak. »
« Claude a multiplié les tentatives pour exploiter différents dépassements de tampon sur la pile et le tas, ou stack et heap buffer overflows, mais n’a pas réussi à déclencher un seul crash ASAN. »
J’étais curieux de comprendre pourquoi Claude n’avait pas trouvé de problèmes de corruption mémoire. Un logiciel de rétro-ingénierie comme radare2, écrit entièrement en C, devrait normalement contenir quelques bugs, peut-être pas facilement exploitables, mais certainement quelque chose pouvant mener à un crash Address Sanitizer (ASAN).
Comme je m’intéresse particulièrement aux corruptions mémoire, j’ai décidé d’y jeter un œil moi-même.
J’ai cloné radare2, puis lancé quelques règles Semgrep afin d’identifier des low-hanging fruits avant de plonger plus profondément et de lire le code ligne par ligne. Il faut préciser que je n’avais jamais consulté cette codebase auparavant et que je n’avais absolument aucune idée d’où chercher.
En parcourant les résultats, j’ai identifié deux vulnérabilités dans un même chemin de code : un pointeur libéré, puis relu, puis libéré de nouveau.
Le bug dans gdbr_threads_list() était causé par un label de nettoyage end, qui libère la liste npid allouée lorsqu’une erreur survient.
« L’or est là où on le trouve. »
C’est la première règle, et la plus importante, lorsqu’on cherche de l’or. Elle s’applique directement à la recherche de vulnérabilités.
En examinant quelques lignes au-dessus de la fonction vulnérable, nous avons trouvé exactement la même logique de gestion d’erreur implémentée dans une autre fonction, gdbr_pids_list(). Il s’agissait de notre deuxième vulnérabilité distincte de type use-after-free (UAF) / double free en 20 minutes.
Ces bugs se trouvaient dans la fonctionnalité de débogage distant GDB, qui permet d’utiliser radare2 contre un serveur GDB exécutant un binaire. Ils pourraient donc potentiellement être exploités à distance pour permettre l’exécution de code.
Ma question était alors la suivante : comment le meilleur LLM dans ce domaine, capable de trouver toutes sortes de vulnérabilités dans des logiciels majeurs, peut-il passer à côté de quelque chose d’aussi trivial? Même un simple grep free() l’aurait mené vers ce chemin de code.
L’IA comme levier, pas comme remplacement
Ce qui nous amène à la conclusion suivante : cette technologie est un excellent levier de mise à l’échelle, donnant accès à une quantité quasi infinie d’agents hackers propulsés par l’IA, capables de trouver des vulnérabilités critiques dans toutes sortes de logiciels. Toutefois, puisqu’elle passe encore à côté de constats évidents, elle ne remplacera pas les chercheurs humains, surtout les hackers d’élite capables d’écrire de la vraie magie technique, comme des exploits multichaînes. L’IA devrait plutôt être vue comme un outil supplémentaire dans l’arsenal du chercheur : elle améliore la productivité et élargit la couverture, sans remplacer l’expertise approfondie.
Ingénieur en sécurité possédant une expérience concrète en opérations SOC, notamment en détection des menaces, en réponse aux incidents et en défense des infrastructures d’entreprise. Il mène activement des recherches en sécurité dans plusieurs domaines.
Ces contenus pourraient vous intéresser
