La politique de divulgation à 90 jours est morte

• La divulgation responsable à 90 jours a perdu son effet protecteur, car les LLM ont accéléré à la fois la découverte et le développement d’exploits
• En 6 semaines, 11 personnes ont signalé le même bug critique de validation de paiement, révélant une redécouverte simultanée
• Un diff de patch React a été transformé en exploit fonctionnel en 30 minutes avec l’aide de l’IA
• Copy Fail et Dirty Frag ont montré que les PoC publics et l’exploitation réelle font s’effondrer les embargos
• Les problèmes critiques doivent être traités immédiatement comme des P0, et les LLM doivent être intégrés dans la chaîne de sécurité

---

Pourquoi le modèle de divulgation responsable à 90 jours s’est brisé

• La fenêtre de divulgation responsable de 90 jours a été conçue en partant du principe que les découvreurs de bugs étaient rares et que le développement d’exploits était lent
• Au cours des 12 derniers mois, les outils utilisés par les défenseurs, les attaquants et les chercheurs sont devenus plus intelligents à un rythme comparable, et les LLM ont presque réduit à zéro le temps nécessaire pour découvrir des vulnérabilités et développer des exploits
• Dans le modèle hérité de 2019, on laissait 90 jours au fournisseur, dans le style de Google Project Zero, avec les hypothèses suivantes
  • très peu de personnes trouveraient le même bug
  • même si quelqu’un d’autre le trouvait, cela prendrait du temps
  • le fournisseur disposerait d’une avance suffisante pour préparer un correctif
  • après publication du patch, il faudrait encore plusieurs jours ou semaines à un attaquant pour en faire de la rétro-ingénierie et produire un exploit fonctionnel
• Toutes ces hypothèses se sont révélées fausses, et la fenêtre de 90 jours est devenue un mécanisme qui donne 90 jours d’avance à ceux qui possèdent déjà le bug, au lieu de protéger les utilisateurs

Cas 1 : 11 personnes signalent le même bug critique en 6 semaines

• Fin avril, un bug grave a été signalé à une entreprise, mais l’équipe de triage a répondu qu’il avait déjà été signalé une première fois en mars et que l’auteur était le 11e rapporteur
• Le bug fonctionnait ainsi : après avoir acheté un produit sur un site web, un attaquant pouvait renvoyer au serveur une réponse qu’il avait modifiée lui-même, et comme il n’y avait aucune vérification de signature sur cette réponse, le serveur l’acceptait telle quelle
  • Par exemple, il était possible d’acheter un article à 5 000 dollars pour 0 dollar, ou de faire passer un achat comme payé sans paiement réel
• Le fait que 11 personnes différentes aient trouvé le même bug critique en environ 6 semaines montre un schéma où des chasseurs de bugs assistés par LLM convergent presque simultanément vers les mêmes vulnérabilités
• Une connaissance liée au BlueWater CTF avait déjà observé, quelques mois plus tôt, que des rapporteurs et workflows sans lien entre eux convergeaient vers les mêmes bugs avec l’aide de LLM
• Le même phénomène a également été observé côté triage
  • @d0rsky a écrit que, lorsqu’une nouvelle vulnérabilité est découverte via des prompts, des compétences et de l’automatisation autour des LLM, une vague de rapports dupliqués sur la même cause racine arrive en quelques jours
  • Si les chercheurs peuvent la reproduire aussi vite, l’inquiétude grandit quant au fait que des black hats puissent faire la même chose avant le patch
• Si 10 personnes l’ont signalé, il peut aussi y avoir des personnes qui ne l’ont pas signalé, et les mêmes LLM sont accessibles non seulement aux chercheurs bienveillants, mais à n’importe qui d’autre
• Le crédit CVE et la bug bounty ne peuvent revenir qu’à une seule personne, donc les 9 autres — ou celles qui n’ont jamais signalé le bug — ne sont liées à aucune horloge de 90 jours
• Dans cette situation, la fenêtre de divulgation de 90 jours ne protège pas les utilisateurs ; elle fait gagner du temps à ceux qui détiennent déjà le bug

Cas 2 : 30 minutes entre un patch React et un exploit fonctionnel

• React a corrigé plusieurs problèmes de sécurité et publié un billet de blog public
  • CVE-2026-23870
  • CVE-2026-44575
  • CVE-2026-44579
  • CVE-2026-44574
  • CVE-2026-44578
• Il a fallu 30 minutes pour lire le patch et produire un exploit fonctionnel sur une application de test locale
• Le problème public concernait un déni de service (DoS), et l’IA a pris en charge l’essentiel de la compréhension du diff, de l’identification du chemin de code vulnérable et de la rédaction du PoC
• Par le passé, transformer un patch public en exploit n-day fonctionnel demandait à un ingénieur en rétro-ingénierie expérimenté plusieurs jours ou semaines, et ce décalage temporel servait de marge de sécurité aux administrateurs pour mettre à jour
• Désormais, un bug simple peut être exploité en quelques minutes, et même un bug complexe en quelques heures, sans qu’un spécialiste chevronné soit indispensable
• Il faut partir du principe qu’un exploit existe dès qu’un patch sort, et remettre le déploiement au prochain créneau de maintenance n’est plus adapté

Cas 3 : Copy Fail et Dirty Frag, deux crises successives dans le noyau Linux

• Au cours des deux dernières semaines, deux vulnérabilités critiques successives ont touché le noyau Linux, toutes deux avec des exploits publics et un impact sur les principales distributions

• Copy Fail

  • Le 29 avril, Xint Code a rendu public Copy Fail
  • Xint Code est l’équipe derrière Theori, présentée comme une équipe victorieuse à 9 reprises au DEF CON CTF
  • Copy Fail correspond à CVE-2026-31431, décrite comme un défaut logique direct dans le sous-système crypto du noyau
  • Sans race condition, avec une fiabilité de 100 %, et grâce à un script Python de 732 octets, il serait possible d’obtenir les privilèges root sur toutes les distributions Linux publiées depuis 2017
  • Ubuntu, RHEL, Amazon Linux, SUSE et d’autres grandes distributions sont touchées
  • La vulnérabilité aurait été trouvée grâce à un scan automatisé par IA du sous-système crypto/ du noyau en environ une heure, après 9 ans d’exposition
  • L’analyse technique est disponible dans le billet de Xint
  • Un correctif a été publié dans le commit mainline a664bf3d603d, avec aussi une mesure d’atténuation consistant à désactiver le module algif_aead
  • Par la suite, des indices ont montré qu’un acteur iranien avait exploité cette vulnérabilité pour compromettre des serveurs Ubuntu et les réutiliser comme nœuds d’une campagne DDoS
  • Il n’a fallu que quelques jours pour passer d’une élévation de privilèges noyau découverte par IA à un PoC public puis à une militarisation par un acteur étatique

• Dirty Frag

  • Environ une semaine plus tard, le 7 mai, Hyunwoo Kim(@v4bel) a rendu public Dirty Frag
  • Dirty Frag enchaîne CVE-2026-43284 et CVE-2026-43500
  • Il relie deux vulnérabilités présentes dans l’IPSec ESP (esp4/esp6) du noyau et dans le module réseau RxRPC
  • Il s’agit de la même famille de bugs que Copy Fail et Dirty Pipe, fondée sur la même technique de corruption du page cache, mais avec un chemin d’attaque différent
  • Dirty Frag fonctionne même si la mesure d’atténuation de Copy Fail est appliquée
    • Même si algif_aead est placé sur liste noire, Dirty Frag n’utilise pas ce module
  • Il permet une élévation déterministe d’un utilisateur non privilégié à root, et fonctionnerait sur Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 et d’autres grandes distributions
  • La compilation et l’exécution tiennent en une seule ligne de commande

• Processus de divulgation de Dirty Frag et effondrement de l’embargo

  • Hyunwoo Kim l’a signalé les 29 et 30 avril à [email protected] et a soumis publiquement les patches
  • Le 7 mai, une coordination a eu lieu avec la liste de diffusion linux-distros, avec accord sur un embargo de 5 jours
  • Le même jour, quelques heures plus tard, un tiers sans lien avec l’affaire a publié des détails d’exploitation sur la vulnérabilité ESP, brisant l’embargo
  • Après concertation avec les mainteneurs des distributions, Hyunwoo a publié l’analyse complète de Dirty Frag, le code d’exploit et un PoC fonctionnel
  • À ce moment-là, aucune distribution Linux ne proposait encore de correctif
  • À l’heure actuelle, seul CVE-2026-43284, c’est-à-dire le volet ESP, dispose d’un correctif mainline, tandis que CVE-2026-43500, le composant RxRPC, n’aurait toujours pas de correctif upstream
  • Ubuntu, Red Hat et Tenable, entre autres, ont publié leurs propres avis

• Exploitation réelle de Dirty Frag

  • L’équipe Microsoft Defender a confirmé une exploitation réelle limitée dans les 24 heures suivant la publication
  • Les attaquants auraient obtenu un accès SSH, déployé des binaires ELF, obtenu les privilèges root via su, modifié les paramètres d’authentification, effacé des fichiers de session et effectué des mouvements latéraux
  • CTS(@gf_256) a résumé la situation par « responsible disclosure is dead🤦 »

Ce qui est réellement mort

• La fenêtre de divulgation de 90 jours n’est pas un problème à corriger : c’est un modèle terminé
• Ce modèle était adapté à un monde où les découvreurs étaient rares et où le développement d’exploits était lent, mais les LLM multiplient les découvreurs et accélèrent le développement d’exploits
• Si 10 personnes sans lien trouvent le même bug en 6 semaines, et si l’IA peut transformer un diff de patch en exploit fonctionnel en 30 minutes, alors la fenêtre de 90 jours ne protège plus personne
• Avec Copy Fail, il n’a fallu que quelques jours pour passer d’un scan par IA à un PoC public puis à une militarisation par un acteur étatique
• Avec Dirty Frag, l’embargo a volé en éclats en quelques heures à cause d’un tiers ayant trouvé indépendamment la même famille de bugs
• Dans un environnement où la même vulnérabilité est redécouverte indépendamment et simultanément par plusieurs chercheurs et outils d’IA, il devient difficile de maintenir une coordination de divulgation
• Le cycle mensuel de patchs est lui aussi terminé
  • Une fenêtre de 30 jours entre vulnérabilité et correctif suppose que l’attaquant avance moins vite que le train de release
  • Quand Microsoft observe une exploitation réelle de Dirty Frag en 24 heures, la fenêtre mensuelle de maintenance n’est plus une marge de sécurité, mais une fenêtre d’attaque
• La stratégie qui consiste à attendre l’avis de sécurité est elle aussi terminée
  • Pendant que les défenseurs lisent la description CVE, les attaquants lisent git log --diff-filter=M
  • L’avis de sécurité est un artefact downstream ; le véritable signal, c’est le diff du patch

Ce que l’industrie doit changer

• La conclusion est que tous les problèmes de sécurité critiques doivent être considérés comme des P0 et corrigés immédiatement
• Plus question de « sous 24 heures », « au prochain sprint » ou « après évaluation de l’impact » : il faut arrêter ce qu’on est en train de faire et corriger sur-le-champ
• Les déploiements en production sont certes complexes et soumis à la gestion du changement, mais le paysage des menaces n’attend pas les procédures de changement

• Fournisseurs

  • Le temps commence à s’écouler dès l’instant où un rapport de bug critique arrive
  • Le point de départ n’est ni la fin du triage ni la prise en charge par l’ingénierie, mais l’instant de réception du signalement
  • Si quelqu’un l’a signalé, il faut partir du principe que 10 autres l’ont déjà, et qu’au moins l’un d’eux n’est pas bienveillant

• Chercheurs

  • Il ne faut pas conserver longtemps un bug critique et il faut pousser vers la fenêtre de divulgation la plus courte possible
  • Si le fournisseur ne peut pas corriger en une semaine, c’est un problème du fournisseur, pas un problème de divulgation
  • L’ancienne politesse qui consistait à « laisser du temps » n’avait de sens que si l’on était l’unique découvreur, or il est désormais probable que ce ne soit plus le cas

• Gestion des vulnérabilités

  • La gestion des vulnérabilités doit devenir temps réel
  • « Scan hebdomadaire, triage pendant le sprint, patch au cycle prévu » correspond à une timeline où les attaquants sont déjà repartis
  • Le nouveau temps maximal de réponse pour un problème critique n’est plus de quelques jours, mais de quelques heures, et même cela peut déjà être trop lent

Pourquoi les blue teams doivent intégrer les LLM dans leur pipeline de défense

• Les attaquants ont déjà intégré les LLM dans leur pipeline d’exploitation, et la défense doit avancer à la même vitesse
• Les LLM doivent être intégrés au moment du push de code
  • Il faut exécuter une revue de sécurité assistée par IA dans le pipeline CI à chaque pull request, merge et déploiement
  • Cela doit tourner au moment du push, comme un linter ou des tests unitaires, et non comme un audit trimestriel ou une vérification a posteriori
  • Les vulnérabilités doivent être détectées avant d’atteindre la production, car le coût d’une correction en revue de PR est bien inférieur à celui d’une correction après publication d’un CVE
• Les LLM doivent aussi être intégrés à l’analyse des patchs
  • Lorsqu’une dépendance upstream publie un patch de sécurité, le pipeline doit automatiquement récupérer le diff, analyser les changements, déterminer s’ils affectent le code interne et lever une alerte
  • Cela doit se produire automatiquement en quelques minutes dès qu’un patch apparaît dans un dépôt public, sans dépendre d’une lecture humaine des listes de diffusion ou de l’ouverture manuelle d’un ticket Jira
  • Si Xint Code a trouvé Copy Fail en une heure de scan automatisé, il faut scanner ses propres dépendances de la même manière
• Les LLM doivent aussi servir au scan des dépendances
  • La supply chain n’est jamais plus solide que sa dépendance transitive la plus faible
  • Un scanner de dépendances basé sur l’IA peut suivre l’impact d’une vulnérabilité dans l’arbre des dépendances, identifier les versions affectées et proposer des chemins de mise à niveau
  • Cela doit tourner en continu, pas une fois par semaine
• Les patchs doivent être testés par l’IA avant leur publication
  • Si, comme dans le cas de React, un LLM peut transformer un patch en exploit en 30 minutes, les défenseurs doivent vérifier avec les mêmes outils avant publication
  • Il faut s’assurer que le patch corrige réellement le problème et n’en introduit pas de nouveaux
  • Il faut aussi s’en servir pour générer des tests de régression et vérifier si le même motif existe ailleurs dans la base de code
• La fenêtre entre « vulnérabilité existante » et « vulnérabilité exploitée » se rapproche de zéro, et la défense doit automatiser à la même vitesse que l’attaque
• Il y aura davantage de zero-day exploités plus vite dans des environnements réels, en raison des mêmes outils, d’une barrière d’entrée plus basse, d’un plus grand nombre de découvreurs et de timelines raccourcies
• Les équipes qui survivront à cette transition sont celles qui auront fait de l’IA un composant de premier plan de leur pipeline de sécurité avant d’y être forcées

Conclusion

• La nouvelle normalité, c’est l’administrateur système qui lit l’avis Dirty Frag, constate qu’il n’y a pas encore de patch, que l’exploit est déjà public, que Microsoft observe une exploitation réelle, que la mesure d’atténuation consiste à désactiver les modules IPSec, et qu’il doit maintenant intervenir sur 400 serveurs
• La politique de divulgation à 90 jours, le cycle mensuel de patchs et l’hypothèse selon laquelle il existe un délai entre divulgation et exploitation sont tous morts
• Ce qui reste, c’est la capacité à agir vite, à automatiser fortement et à traiter les bugs critiques comme de véritables urgences
• La vague d’IA qui a brisé l’ancien modèle rend aussi possible un nouveau modèle fondé sur des patchs rapides, des scans automatisés, du threat intelligence en temps réel et des revues de code assistées par IA
• Les outils existent déjà ; tout l’enjeu est de savoir si les défenseurs les utiliseront avant les attaquants, et pour l’instant, ce sont les attaquants qui ont l’avantage

[GN⁺]

Avis sur Lobste.rs

• Difficile de ne pas être d'accord à contrecœur. On a aussi enquêté sur ce sujet dans notre entreprise, et le délai du patch à l'exploit est pratiquement immédiat.

• La politique de divulgation responsable a toujours été une fiction à laquelle les gens faisaient semblant de croire par politesse. Dès le départ, c'était surtout une façon de suivre le mouvement, et les outils de découverte de vulnérabilités basés sur les LLM n'ont fait que révéler cette réalité.

• Je trouve assez ironique que ce texte lui-même ait l'odeur d'un texte écrit par un LLM.

  • Ça se tient. Si on a une idée originale, il faut la publier avant que quelqu'un d'autre ne le fasse. La pensée critique et l'introspection sont mortes, et si tu ne publies pas sur ton blog dans les 39 minutes qui suivent une idée, quelqu'un d'autre le fera avant toi :P
  • Ça ne me donne pas cette impression. Ce style d'écriture existait déjà depuis longtemps dans les textes techniques d'avant les LLM, et les principaux LLM écrivent en général un peu différemment de ce texte.
  • Ça se lit comme une pub alarmiste.
  • Que ce soit bien ou mal, on dirait qu'aujourd'hui les choses suivent simplement ce cours.

• Peut-être que ce qui est mort, c'est plutôt l'époque des programmes C artisanaux de niche utilisés dans des situations critiques pour la mission.