L’industrialisation de la génération d’exploits de piratage basée sur les LLM approche

• Des agents basés sur Opus 4.5 et GPT-5.2 ont généré plus de 40 exploits dans 6 scénarios en utilisant une vulnérabilité zero-day de QuickJS
• GPT-5.2 a résolu toutes les tâches, et Opus 4.5 a résolu toutes sauf deux, montrant des capacités autonomes d’analyse de code, de débogage et de construction de chaînes d’exploit
• Les résultats expérimentaux suggèrent que le développement d’exploits pourrait être limité non par le nombre de hackers humains, mais par le débit de traitement des tokens
• La détection de vulnérabilités et la génération d’exploits ont déjà atteint un stade où les performances augmentent proportionnellement au volume de tokens injectés
• La nécessité de repenser l’automatisation des cyberattaques et les cadres d’évaluation de la sécurité est mise en avant

---

Aperçu de l’expérience

• Réalisation d’une expérience de génération d’exploits ciblant une vulnérabilité zero-day de l’interpréteur JavaScript QuickJS à l’aide d’Opus 4.5 et de GPT-5.2
  • Application de diverses techniques de mitigation des exploits (ASLR, NX, RELRO, CFI, shadow stack, seccomp, etc.)
  • Les agents ont atteint plusieurs objectifs comme l’obtention d’un shell, l’écriture de fichiers et la connexion à un C2
• GPT-5.2 a résolu tous les scénarios, et Opus 4.5 a résolu toutes les tâches sauf deux
  • Chaque exécution était limitée à 30 millions de tokens maximum, pour un coût d’environ 30 dollars
  • La tâche la plus difficile a été résolue avec 50 millions de tokens, environ 3 heures et un coût de 50 dollars
• GPT-5.2 a finalisé un exploit d’écriture de fichier dans un environnement avec sandbox seccomp et shadow stack activées, via un appel de fonction en 7 étapes exploitant la chaîne des gestionnaires exit de glibc

Limites de l’expérience

• QuickJS est bien plus petit et moins complexe qu’un véritable moteur de navigateur, ce qui limite la généralisation des résultats
• Les exploits générés n’ont pas découvert de nouvelles vulnérabilités dans les mécanismes de protection eux-mêmes, mais ont exploité des points de faiblesse déjà connus dans le déploiement
• La vulnérabilité de QuickJS elle-même a été découverte récemment, et la méthode de résolution de GPT-5.2 est considérée comme une nouvelle construction de chaîne non documentée auparavant

L’industrialisation de l’intrusion

• Par « industrialisation », on entend un état dans lequel la capacité offensive d’une organisation est déterminée non par ses effectifs, mais par son débit de tokens
• Deux conditions sont nécessaires pour cela
  • Des agents basés sur des LLM doivent pouvoir explorer de manière autonome dans l’environnement
  • Il doit exister un système de validation précis et rapide
• Le développement d’exploits est un cas idéal qui remplit ces conditions
  • L’environnement est facile à mettre en place et la procédure de validation est claire
  • Par exemple, pour un exploit d’obtention de shell, il est possible de vérifier le succès via une connexion réussie à un port listener
• En revanche, des activités comme l’intrusion nécessitant des interactions en temps réel, l’élévation de privilèges, le maintien d’un accès persistant ou l’exfiltration de données sont plus difficiles à industrialiser
  • Car un comportement erroné en environnement réel peut mener à une détection

Stade actuel

• La détection de vulnérabilités et le développement d’exploits progressent déjà proportionnellement au volume de tokens engagé
  • La même tendance a été observée dans le projet Aardvark d’OpenAI
  • Dans l’expérience aussi, la limite venait du budget, pas des performances du modèle
• L’automatisation du piratage dans de vrais réseaux reste encore incertaine
  • Selon un rapport d’Anthropic, il existe des cas où des équipes de hackers chinoises ont tenté des attaques via une API
  • En revanche, il n’existe pas encore de cas commercialisé d’agent SRE (site reliability engineering) entièrement automatisé
• Si l’automatisation du SRE réussit, l’automatisation du piratage dans des réseaux adverses a aussi de fortes chances de devenir possible

Conclusion et recommandations

• Cette expérience change la perception de l’ampleur et du calendrier du possible en matière d’automatisation dans le cyberespace
• Les méthodes actuelles d’évaluation des modèles (CTF, anciennes vulnérabilités, données synthétiques) sont inadaptées pour mesurer de réelles capacités d’attaque zero-day
• Les laboratoires de pointe et les organismes de sécurité de l’IA doivent mener des évaluations sur de véritables cibles zero-day (par ex. le noyau Linux, Firefox)
  • Il est nécessaire de publier des rapports du type : « X centaines de millions de tokens ont permis de générer Y exploits »
• Des évaluations sur des équipements réels comme les firmwares IoT sont également nécessaires
  • La possibilité est avancée de générer des exploits concrets en moins d’une semaine avec des agents basés sur Opus 4.5 ou GPT-5.2
• Il est recommandé aux chercheurs et aux ingénieurs de mener eux-mêmes des expériences et de publier les résultats
  • Le code expérimental et les données sont publiés dans un dépôt GitHub

[GN⁺]

Réactions sur Hacker News

• Le défi le plus difficile donné à GPT‑5.2 était de trouver comment écrire une chaîne à un chemin précis sur le disque
  C’était un environnement QuickJS avec toutes les protections activées : ASLR, mémoire non exécutable, full RELRO, CFI fine, shadow stack matérielle, sandbox seccomp, etc.
  GPT‑5.2 a résolu le problème via la chaîne des gestionnaires de sortie de glibc, avec un appel de fonctions en 7 étapes. Résultat vraiment stupéfiant

  • Je me demande s’il ne faudrait pas tout simplement supprimer ces mécanismes d’atténuation
    En pratique, un exploit suit souvent la séquence « trouver la vulnérabilité (difficile) », puis « percer plusieurs couches d’atténuation inutiles (pénible mais faisable) »
    Les atténuations probabilistes marchent contre les attaques probabilistes, mais les attaquants cherchent délibérément les faiblesses
  • Au fond, il y a trop de trous au bas de la pile en langage machine
    À l’avenir, on regrettera probablement de ne pas être passés plus tôt à WASM
    D’ici là, on continuera à empiler des atténuations matérielles tout en s’accrochant à ce vieux problème d’écrasement de pile
  • « le gestionnaire de sortie de glibc »… ça donne des frissons
  • Aujourd’hui, la kill chain exploite le plus souvent plusieurs bugs en chaîne
    Je le sais bien, c’est mon métier, et je ressens une impuissance grandissante
  • Ce cas montre à quel point QuickJS, compilé en C, est vulnérable aux LLM
    Par exemple via une fuite de pointeur libc à l’aide d’un Use‑After‑Free
    Avec Rust, ce serait bien plus difficile, même si une défense complète reste compliquée quand il y a beaucoup d’appels libc

• L’exploit de GPT‑5.2 n’a pas cassé de nouvelles atténuations ; il a exploité des failles d’implémentation déjà connues
  Les hackers humains ne cassent pas non plus de nouvelles atténuations en général
  En revanche, dans le domaine des CTF, les LLM arrivent de plus en plus souvent à résoudre des défis pwn en one-shot
  Ces progrès devraient faire tomber les implémentations d’atténuation imparfaites et stimuler la recherche sur la modélisation formelle des exploits

  • On dit que la « modélisation formelle des exploits » est un domaine encore peu mûr ; je serais curieux d’avoir des références utiles

• Du point de vue d’un chercheur en sécurité, l’API de primitives de lecture/écriture produite par le LLM n’est qu’une simple recombinaison d’API existantes
  Ce n’est pas vraiment une nouvelle technique, plutôt quelque chose qui ressemble à un binaire-jouet de CTF
  En revanche, comme les modèles récents d’OpenAI tendent à ne pas générer de vrai code d’exploit, je me demande s’il y a eu recours à un contournement de prompt

• L’auteur soulève des points intéressants, mais je ne suis pas particulièrement inquiet
  Ce type d’outil peut aussi être exploité symétriquement par les défenseurs
  On peut par exemple ajouter des tests de sécurité automatisés en lançant une « LLM Red Team » à l’étape CI

  • Mathématiquement, ce n’est pas symétrique
    L’attaquant n’a besoin de réussir qu’une seule fois, alors que le défenseur doit réussir à chaque fois
    Les modèles actuels ont des performances pass@x supérieures de 20 à 30 % à maj@x
    Cela dit, faire tourner une boucle Red vs Blue améliorera quand même le niveau de sécurité
  • Dans les systèmes complexes, cette symétrie se brise
    L’attaquant n’a besoin de trouver qu’un seul échec, alors que le défenseur doit tout bloquer
  • C’est déjà utilisé de manière défensive
    Exemple : le projet Big Sleep de Google Project Zero
    La liste des vulnérabilités associées est visible ici
  • Il ne peut pas y avoir de symétrie
    L’attaquant peut militariser un seul bug, tandis que le défenseur doit trouver tous les bugs
    C’est une asymétrie structurelle du type « any vs all »
  • Il y a beaucoup trop de logiciels non maintenus
    Au final, les entreprises de LLM seront les seules vraies gagnantes, en vendant des tokens aux deux camps

• Il est intéressant que Codex 5.2 ait trouvé l’exploit le plus complexe
  J’utilise surtout Opus 4.5 moi aussi, mais le mode Extra High thinking de Codex 5.2 est clairement puissant
  Je ne crois pas au discours sur le ralentissement des progrès des LLM. Au contraire, c’est juste que les tâches sont devenues tellement difficiles qu’on le perçoit moins

  • En réalité, il n’a pas « trouvé » l’exploit ; il a écrit le code qui exploite une vulnérabilité déjà fournie
    Les logs sont disponibles dans ce dépôt
  • Les modèles d’Anthropic sont de type utilisateur d’outils, OpenAI Codex High de type relecteur/correcteur, et Gemini de type artiste créatif
    Chacun a son propre style
  • Les « tâches suffisamment difficiles » sont pour la plupart enfermées dans de la PI interne aux entreprises
    Elles ne seront pas rendues publiques tant que leur valeur commerciale n’aura pas disparu

• QuickJS est à l’origine un projet-jouet avec beaucoup de vulnérabilités non corrigées
  Un exploit sur une cible réelle comme curl serait bien plus intéressant

• On voit coexister l’idée que les LLM écrivent de très bons exploits et celle qu’ils produisent des rapports de bugs inutiles
  Les deux peuvent-ils être vrais à la fois ?

  • Les deux sont tout à fait possibles
    La qualité d’un LLM varie selon le prompt de l’utilisateur et sa capacité d’interprétation
    Entre les mains d’un expert qui s’en sert de manière sélective, on peut obtenir d’excellents résultats
  • Un exploit se juge clairement sur le critère « est-ce que ça fonctionne ? », alors qu’un rapport de CVE est bien plus difficile à vérifier
    Les rapports générés automatiquement représentent une lourde charge pour les mainteneurs
  • En pratique, la qualité varie énormément selon la manière de l’utiliser
    Si on demande simplement « trouve les vulnérabilités de ce programme », il dira beaucoup de bêtises, mais
    si on lui fournit une boucle de test et un environnement, il s’améliore de manière itérative jusqu’à produire un résultat réellement fonctionnel
  • Un exploit a un critère de réussite clair, ce qui cadre bien avec la ténacité itérative des LLM
    À l’inverse, un rapport de bug est ambigu et difficile à évaluer
  • La structure budgétaire est différente aussi
    Par exemple, si sur 100 $ on mélange un vrai problème valant 50 $ avec 5 000 faux rapports valant 0,01 $,
    il devient difficile de repérer le véritable diamant

• La description de la sandbox était floue, donc j’étais sceptique au début
  En regardant le dépôt de l’auteur, on voit que l’objectif était « écrire la chaîne ‘PWNED’ dans /tmp/pwned »
  Donc, ce n’était pas une évasion de sandbox, mais simplement une restriction d’écriture de fichier

  • L’ensemble du dépôt et de l’article est présenté d’une manière un peu susceptible d’induire en erreur
    Le fait de lui faire construire une API de primitives OOB R/W n’était guère plus qu’une réutilisation de milliers d’exemples déjà présents sur GitHub

• La phrase « à l’avenir, la capacité de piratage d’un État ou d’une organisation sera déterminée non plus par le nombre de hackers, mais par le débit de traitement des tokens » m’a marqué

  • En réalité, il est probable que ces organisations analysent plutôt les schémas de code bâclés des LLM, puis fassent écrire par des humains des exploits génériques

• Le fait que la barrière à l’entrée pour produire du logiciel et la barrière à l’entrée pour le piratage baissent en même temps est une combinaison explosive
  Il faut désormais de nouvelles plateformes avec des garde-fous de sécurité et de la vérifiabilité
  Il est risqué de dépendre de code produit par des non-spécialistes

  • Le troisième paragraphe mentionnait au départ le déséquilibre entre « un seul exploit » et « défendre l’ensemble du système » ; je me demande pourquoi il a été supprimé