Divulgation sauvage : quand un chercheur frustré arme

Un seul chercheur a publié trois zero-days Microsoft Defender en moins d'un mois. L'industrie a observé l'exploitation in-the-wild dans les 72 heures. C'est un signal qu'on a tort de minimiser : la responsible disclosure, en tant que contrat social, est en train de s'effriter.

L'affaire Chaotic Eclipse, en deux temps

Le 2 avril 2026, un chercheur connu sous les pseudonymes Chaotic Eclipse et Nightmare-Eclipse publie sur GitHub un PoC fonctionnel pour BlueHammer (CVE-2026-33825), une race condition TOCTOU dans Microsoft Defender qui permet à un compte standard d'escalader à SYSTEM. Pas de coordination préalable avec le MSRC, pas de fenêtre d'embargo, le code est accompagné d'une notice expliquant que l'auteur publie par frustration face à la gestion antérieure de ses rapports par Microsoft.

Microsoft réagit dans le Patch Tuesday du 14 avril en intégrant le correctif. Entre les deux dates, douze jours pendant lesquels le PoC tourne dans la nature. CISA confirme une exploitation in-the-wild observée dès le 10 avril. Le 17 avril, le même chercheur double la mise en publiant deux nouveaux 0-days Defender — RedSun et UnDefend — qui restent non corrigés à ce jour.

L'affaire n'est pas anecdotique. Elle fait écho à plusieurs épisodes récents : la divulgation sauvage des bugs Microsoft Print Spooler en 2021, les détails techniques publiés par des chercheurs Trend Micro après des désaccords avec ZDI, ou la frustration documentée de plusieurs chercheurs autour de la gestion des bounties Apple. Ce sont des incidents discrets mais récurrents, qui dessinent une tendance.

La responsible disclosure, c'est un deal — et un deal qui demande deux signataires

Le contrat tacite de la responsible disclosure est simple : le chercheur signale un bug, l'éditeur le corrige dans un délai raisonnable, le chercheur attend pour publier les détails, l'éditeur reconnaît publiquement le travail. Les programmes de bug bounty (Microsoft, Google, Apple, HackerOne, Bugcrowd) formalisent cet échange en y ajoutant une rémunération financière.

Le système fonctionne quand les deux parties tiennent leur engagement. Il commence à craquer quand des asymétries s'installent — délais qui s'allongent au-delà du raisonnable, classifications de severity à la baisse pour minimiser les payouts, refus de patcher en invoquant des "design choices" plutôt qu'une vulnérabilité, communication publique qui minore l'apport du chercheur. Et l'écosystème commence à mal vivre lorsque ces incidents se répètent et que la communauté des chercheurs en parle entre elle.

Ce qu'on observe avec Chaotic Eclipse n'est pas un acte isolé d'un cybercriminel. C'est un chercheur compétent qui choisit délibérément la voie la plus dommageable pour faire passer un message. Il sait parfaitement que sa divulgation va être exploitée. Il accepte ce coût comme un levier de négociation, ou simplement comme une protestation contre un système qu'il juge cassé.

Le coût n'est pas porté par Microsoft

C'est ici que la situation devient problématique. Quand un chercheur publie un 0-day en représailles, ce n'est pas Microsoft qui en paie le prix immédiat. Microsoft a des équipes, du temps, des ressources, et un patch peut être préparé et diffusé en deux semaines. Les victimes réelles, ce sont les RSSI et équipes IT qui passent leurs nuits à patcher en urgence des dizaines de milliers de postes, les hôpitaux qui se font ransomwarer parce qu'un poste de l'accueil n'avait pas reçu le KB à temps, les PME industrielles dont le poste de bureau du dirigeant héberge SYSTEM:Authority pendant que LockBit chiffre les serveurs.

Le chercheur qui pratique la divulgation sauvage transfert son frustration sur des cibles qui n'ont aucun rapport avec son différend avec Microsoft. C'est moralement défendable seulement si on considère que la pression sur l'éditeur produira une amélioration systémique qui justifie les dégâts à court terme. C'est un calcul utilitariste qui se discute.

Trois pistes qui me semblent prioritaires

1. Les éditeurs doivent industrialiser leur réponse

Si Microsoft, Apple, Google et les autres veulent éviter la prolifération de cas Chaotic Eclipse, ils doivent traiter chaque rapport sérieux avec une rigueur procédurale audit-able. Délais affichés, classifications justifiées techniquement, communication transparente sur les patches en préparation, et reconnaissance systématique du travail des chercheurs. Le programme MSRC a fait des progrès, mais reste perçu par une partie de la communauté comme opaque sur les arbitrages internes.

2. La communauté doit institutionnaliser des contre-pouvoirs

ZDI (Zero Day Initiative) joue ce rôle pour une partie des chercheurs en achetant les vulnérabilités, en gérant la coordination avec les éditeurs, et en publiant des avis indépendants. Mais ZDI seul ne suffit pas. Il faudrait des observatoires neutres qui documentent publiquement les délais de réponse des éditeurs, les arbitrages contestés, et offrent des voies de recours formelles aux chercheurs avant qu'ils ne basculent vers la divulgation sauvage.

3. Les organisations défensives doivent s'adapter

On ne peut plus considérer la divulgation responsable comme acquise. Quand un PoC sort sur GitHub avant un patch, le délai entre publication et exploitation in-the-wild est désormais de 72 heures, parfois moins. Cela impose de repenser les SLA de patch management, de privilégier des architectures qui résistent à un poste compromis (Zero Trust, segmentation réseau forte, EDR avec détection comportementale), et d'accepter que la veille devienne un canal opérationnel — pas seulement informationnel.

Ce qui va probablement se passer dans les six prochains mois

Trois choses, à mon avis. D'abord, d'autres divulgations sauvages, parce que le précédent Chaotic Eclipse va inspirer des chercheurs qui se sentent eux aussi mal traités. Ensuite, des éditeurs qui durcissent leurs ToS de bug bounty pour pénaliser la divulgation publique anticipée — ce qui aggravera plutôt qu'apaisera la tension. Enfin, l'émergence de plateformes de divulgation alternatives, peut-être européennes, qui se positionneront comme des intermédiaires neutres entre les chercheurs et les éditeurs.

La conséquence opérationnelle pour les organisations est claire : il faut intégrer le risque "0-day publié sans patch" dans la planification de continuité. Cela signifie des architectures de défense en profondeur, une visibilité endpoint de qualité, et des procédures de patch d'urgence testées et chronométrées. Et plus que jamais, une veille active sur les comptes GitHub des chercheurs sécurité — c'est désormais une source IoC légitime.

Conclusion

Chaotic Eclipse n'est ni le premier ni le dernier. Le pattern qu'il dessine — chercheur compétent qui pratique la divulgation sauvage par protestation contre un éditeur — est en train de devenir un risque opérationnel à part entière. Les organisations qui patchent encore "dans la fenêtre de maintenance mensuelle" jouent à un jeu dont les règles ont changé. Celles qui ont industrialisé leur réponse incident et leur capacité à patcher en moins de 72 heures sur l'ensemble du parc s'en sortiront. Les autres alimenteront les statistiques de ransomware du semestre.

Responsible disclosure en 2026 : un contrat social sous tension

La divulgation responsable (responsible disclosure) repose sur un contrat implicite : le chercheur notifie l'éditeur en privé, l'éditeur publie un patch dans un délai raisonnable (généralement 90 jours selon la politique de Google Project Zero), le chercheur publie ses travaux après le patch. Ce contrat est de plus en plus souvent rompu — des deux côtés.

Pourquoi les chercheurs abandonnent la responsible disclosure

La divulgation "sauvage" de zero-days n'est pas irrationnelle. Elle est souvent la réponse à des comportements répétés d'éditeurs qui ont traité les chercheurs de façon inacceptable :

• Absence de réponse : des chercheurs ont documenté des mois de silence total de la part d'éditeurs après notification privée. Sans programme de bug bounty, sans canal de contact sécurité identifié, les rapports se perdent.
• Délais abusifs : des éditeurs qui repoussent indéfiniment la publication du patch au-delà de 90 jours, parfois 12 à 18 mois, avec des justifications changeantes. Le chercheur ne peut pas publier ses travaux, ne peut pas présenter en conférence, ne peut pas être reconnu pour ses découvertes.
• Représailles légales : des éditeurs qui menacent les chercheurs de poursuites en vertu du CFAA (aux États-Unis) ou de lois similaires pour la seule découverte de vulnérabilités, même non exploitées.
• Non-reconnaissance du travail : des éditeurs qui publient un CVSSAdvisory sans mentionner le chercheur ayant découvert la vulnérabilité, privant ce dernier de la reconnaissance qui est souvent son seul bénéfice direct.

Les 72 heures qui ont suivi la publication des trois zero-days Microsoft Defender

Le cas documenté dans cet article — un chercheur publiant trois zero-days Microsoft Defender en moins d'un mois, avec exploitation in-the-wild dans les 72 heures — illustre les conséquences concrètes d'une rupture de la responsible disclosure :

• Phase 0 à 4h : indexation et réplication : les scanners automatiques (Shodan, Censys, Nuclei) détectent la publication. Des forks du PoC apparaissent sur GitHub. Des discussions émergent sur les forums spécialisés.
• Phase 4h à 24h : développement d'exploits adaptés : des acteurs avec des capacités techniques moyennes adaptent le PoC à des scénarios d'exploitation spécifiques. Des services "exploit-as-a-service" intègrent les nouvelles CVE.
• Phase 24h à 72h : exploitation active : des campagnes d'exploitation automatisées ciblent les instances vulnérables identifiées lors de la phase de scan. Les premières victimes signalent des incidents.
• Phase 72h+ : attribution et réponse : Microsoft publie un advisory d'urgence hors cycle Patch Tuesday. Les entreprises qui ont déployé le patch sont protégées ; les autres sont actives cibles pendant les jours suivants.

Ce que les RSSI doivent faire face à la divulgation publique sans patch

Quand un zero-day est divulgué publiquement sans patch disponible, les équipes sécurité doivent activer un processus spécifique :

1. Évaluation de l'exposition : identifier en moins de 4 heures tous les systèmes de votre SI utilisant le composant vulnérable, leur exposition réseau (Internet vs interne), et les données ou systèmes à risque s'ils sont compromis.
2. Mesures compensatoires immédiates : si le composant peut être désactivé sans impact opérationnel majeur, désactivez-le. Si non, implémentez des restrictions d'accès (filtrage IP, désactivation de la fonctionnalité vulnérable si possible, virtual patching WAF).
3. Communication avec l'éditeur : contactez l'éditeur pour obtenir un ETA sur le patch et des informations sur les mesures compensatoires recommandées. Cette communication doit être documentée.
4. Threat hunting ciblé : lancez une campagne de threat hunting sur les IoC publiés avec le zero-day. Si les 72 premières heures sont dépassées, des systèmes peuvent déjà être compromis sans que l'alerting standard l'ait détecté.

Foire aux questions — Responsible disclosure et zero-days

Quelle est la politique de divulgation standard des grandes entreprises tech ?

Google Project Zero impose un délai de 90 jours à l'éditeur pour publier un patch avant divulgation publique, avec une extension possible de 14 jours si un patch est en cours de déploiement. Microsoft Security Response Center (MSRC) recommande 90 jours mais négocie des extensions selon les cas. Apple Security vise 90 jours. Ces politiques ont contribué à réduire les délais moyens de correction, mais des éditeurs de taille moyenne n'ont pas les ressources pour les respecter systématiquement.

Les programmes de bug bounty résolvent-ils le problème de la responsible disclosure ?

Partiellement. Les programmes de bug bounty bien financés (Google VRP, Microsoft Bug Bounty, HackerOne, Bugcrowd) ont significativement amélioré les incitations économiques pour les chercheurs à passer par la voie coordonnée. Mais ils ne couvrent pas tous les éditeurs, les montants sont parfois insuffisants pour les vulnérabilités les plus critiques (comparés au marché des zero-days exploits), et ils ne résolvent pas le problème des éditeurs qui ne respectent pas les délais de correction même quand ils ont reçu un rapport.