Divulgation sauvage : quand un chercheur frustré arme l'attaquant

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.