Full disclosure à marche forcée : quand les chercheurs perdent patience avec Microsoft

En mai 2026, un chercheur anonyme a mis Microsoft en difficulté six fois en six semaines. Six vulnérabilités Windows non patchées, six PoC sur GitHub sans coordination ni délai, des milliers d'administrateurs qui courent encore après les mitigations. La question n'est pas "est-ce légal ?" — c'est "pourquoi en est-on arrivé là, et qu'est-ce que ça change pour vous ?"

Nightmare-Eclipse : six failles, six semaines, un message sans ambiguïté

Le 13 mai 2026, le lendemain du Patch Tuesday de mai — choix de timing délibérément provocateur — un chercheur opérant sous les pseudonymes "Chaotic Eclipse" et "Nightmare-Eclipse" publie simultanément deux preuves de concept sur GitHub : YellowKey, un contournement de BitLocker, et GreenPlasma, une escalade de privilèges jusqu'au niveau SYSTEM. Pas de note d'alerte préalable à Microsoft. Pas de délai de grâce de 90 jours. Pas de négociation. Le code est public, compilé, utilisable immédiatement par n'importe qui.

Six jours plus tard, rebelote : MiniPlasma, une troisième faille d'escalade de privilèges, entièrement fonctionnelle sur Windows 11 entièrement patché. En remontant la chronologie, on découvre que ce n'est pas la première fois : BlueHammer (CVE-2026-33825) et RedSun, deux LPE divulgués en avril 2026 de la même façon, avaient commencé à être exploitées dans la nature quelques jours après leur publication. Barracuda Networks a dénombré six failles publiées en six semaines par ce même chercheur — une cadence que l'industrie n'avait pas vue depuis SandboxEscaper en 2018-2019.

Ce qui distingue Nightmare-Eclipse des simples "bug bounty droppers", c'est l'argumentation. Dans un post GitHub accompagnant MiniPlasma, le chercheur explique que la vulnérabilité sous-jacente avait été signalée à Microsoft Security Response Center (MSRC) en 2020. Six ans de rapports, d'échanges et de correctifs partiels sans résolution complète. Ce n'est pas un caprice : c'est l'aboutissement documenté d'une frustration institutionnalisée face à un processus qui ne fonctionne pas.

Le résultat opérationnel est sévère. YellowKey a nécessité une mitigation d'urgence de Microsoft trois jours après la divulgation — trois jours pendant lesquels n'importe qui avec un accès physique à un laptop Windows pouvait contourner BitLocker. GreenPlasma et MiniPlasma restent sans patch officiel à ce jour. Les équipes SOC du monde entier ont dû intégrer en urgence des règles Sigma et YARA artisanales pour détecter des tentatives d'exploitation, en attendant des correctifs qui n'arrivent pas.

La politique de divulgation coordonnée de Microsoft : une promesse à géométrie variable

Microsoft dispose formellement d'un programme de Security Vulnerability Research (MSVR) et d'une politique de divulgation coordonnée (CVD) qui prévoit un délai standard de 90 jours entre le signalement et la publication d'un correctif. Sur le papier, c'est raisonnable. En pratique, c'est beaucoup plus compliqué.

Le problème est systémique. Microsoft reçoit des milliers de rapports de vulnérabilité par an. Le pipeline complet — triage, validation, priorisation, développement du correctif, tests de régression sur des centaines de configurations Windows, validation finale, intégration dans un Patch Tuesday — peut prendre 180, 270, voire 365 jours ou plus. Et pendant tout ce temps, le chercheur est censé rester silencieux, souvent sans mise à jour sur l'avancement de son rapport.

Google Project Zero a documenté cette réalité avec ses analyses annuelles. Selon les données publiées en 2024, 15% des vulnérabilités Windows reportées dépassent 120 jours avant correction. Pour les failles affectant des composants complexes comme le kernel ou WinRE, ce taux monte à 27%. Ces chiffres sont en amélioration par rapport à 2020, mais ils restent significatifs — surtout pour un chercheur qui attend depuis 2020.

Il faut ajouter un facteur financier souvent oublié : Microsoft ne rémunère pas les chercheurs qui publient sans coordination. La bug bounty est conditionnée à la coopération. Nightmare-Eclipse a donc perdu toute rémunération potentielle en choisissant la full disclosure — ce geste était délibéré, non motivé par l'argent mais par la conviction que toutes les voies normales étaient bouchées.

BlueHammer et RedSun : les précédents qui ont tout changé

Pour comprendre la rupture, il faut remonter à BlueHammer (CVE-2026-33825) et RedSun, les deux failles publiées en avril 2026. BlueHammer avait été signalé au MSRC en janvier 2026. Microsoft a livré un patch — mais incomplet. Un variant de l'exploitation restait fonctionnel. Le chercheur a reporté le bypass. Microsoft a reconnu le problème. Nouveau délai. RedSun a suivi le même schéma : signalement, attente, patch partiel, bypass résiduel.

La conséquence directe : quelques jours après la publication publique de BlueHammer et RedSun, des groupes cybercriminels ont intégré les exploits dans leurs toolkits. Recorded Future et Mandiant ont détecté des campagnes d'exploitation active dans les 72 heures suivant la mise en ligne. C'est ce précédent qui a informé les décisions suivantes du chercheur.

La question qu'il pose implicitement est inconfortable mais légitime : ces acteurs malveillants n'avaient-ils pas déjà accès à ces failles avant même la publication publique ? Très probablement oui. Le marché des zero-days est florissant — des failles de ce type se négocient entre 50 000 et 250 000 dollars sur des marchés spécialisés. Dans ce contexte, garder une faille secrète en attendant un patch qui ne vient pas protège-t-il vraiment les utilisateurs ? La réponse n'est pas simple, mais la question mérite d'être posée.

Full disclosure vs divulgation responsable : 30 ans de débat toujours ouvert

Le débat n'est pas nouveau. Il remonte aux années 1990, quand les premiers chercheurs ont commencé à publier des failles pour forcer les éditeurs à patcher. Le terme "responsible disclosure" a été popularisé autour de 2000 par Rain Forest Puppy, en réaction aux pratiques de full disclosure totale de groupes comme Bugtraq. Depuis, trois modèles se sont structurés :

Google Project Zero a imposé une norme en 2014 : 90 jours de délai, puis publication quelle que soit l'avancée du patch. Cette politique a été très controversée — Microsoft s'en est plaint publiquement à plusieurs reprises. Mais elle a eu un effet mesurable : les délais moyens de patch chez les grands éditeurs ont diminué significativement dans les cinq ans suivant son adoption généralisée. La pression publique fonctionne. C'est un fait empirique documenté par Carnegie Mellon CERT/CC.

Le cas Nightmare-Eclipse va plus loin : il n'y a pas eu de délai du tout pour certaines failles. C'est du full disclosure pur, fondé non sur une idéologie abstraite mais sur une expérience cumulée de mauvaise foi perçue de l'éditeur. Ce chercheur n'est pas un idéologue — c'est un praticien qui a épuisé toutes les voies normales et tiré les conclusions qui s'imposaient à lui.

La vraie question pour notre industrie n'est pas "Nightmare-Eclipse a-t-il bien fait ?" La vraie question est : "Pourquoi en est-on arrivé là, et comment éviter que ça se reproduise ?" Et là, les réponses sont inconfortables pour Microsoft.

Ce que ça change concrètement pour les RSSI et administrateurs Windows

Pour les praticiens qui gèrent des parcs Windows en production, la série de divulgations de Nightmare-Eclipse illustre un problème structurel : la dépendance totale au Patch Tuesday mensuel crée une fenêtre de vulnérabilité prévisible et intenable quand des PoC publics circulent librement.

La veille vulnérabilité ne peut plus se limiter aux flux NVD/CVE officiels. YellowKey, GreenPlasma et MiniPlasma ont été exploitables pendant des jours sans CVE attribuée et sans correctif. Les équipes SOC qui s'appuient uniquement sur les alertes CERT-FR ou NVD ont été aveugles pendant cette fenêtre. Surveiller les dépôts GitHub de chercheurs connus, les flux Twitter/X de la communauté OffSec, les publications sur exploit-db devient une composante non négociable de la veille proactive. Si vous n'avez pas cette capacité en interne, faites-vous accompagner.

BitLocker TPM-only n'est pas une protection suffisante pour les appareils mobiles. YellowKey l'a démontré brutalement. L'ANSSI recommande le mode Enhanced PIN depuis 2021. Si vos politiques considèrent que BitLocker sans PIN de démarrage suffit sur les laptops d'entreprise, il faut réviser cette hypothèse dès maintenant — pas "après le prochain audit". Le confort utilisateur ne justifie pas ce niveau de risque.

La gestion des patches doit intégrer une procédure de mitigation d'urgence. Quand Microsoft publie une mitigation workaround avant le patch, vos équipes doivent pouvoir la déployer en quelques heures via GPO, Intune ou SCCM. Si votre processus de change management standard prend 72 heures, vous êtes structurellement vulnérables face aux failles publiées en full disclosure. Définissez dès maintenant un circuit d'approbation accéléré pour les urgences de niveau critique.

Les LPE ne sont pas des vulnérabilités de second rang. Une erreur fréquente est de traiter les Local Privilege Escalation comme moins urgentes que les Remote Code Execution, au motif qu'elles nécessitent un accès local préalable. C'est dangereux. Dans un scénario de post-exploitation réel — après un phishing, une fuite de credentials ou un mouvement latéral — une LPE SYSTEM transforme un accès limité en compromission totale. GreenPlasma et MiniPlasma sont exactement ce type d'outil. Traitez-les comme une priorité.

La relation avec les chercheurs externes est un actif stratégique. Pour les organisations qui ont des programmes de bug bounty ou collaborent avec des chercheurs indépendants : le processus de traitement des signalements doit être transparent et réellement respecté. Les chercheurs bien traités coopèrent. Les chercheurs frustrés publient. Ce n'est pas du sentimentalisme — c'est de la gestion du risque de sécurité opérationnelle.

Conclusion : ce que Nightmare-Eclipse a vraiment changé

L'affaire laisse plusieurs enseignements durables. La frontière entre "faille locale peu critique" et "vecteur d'attaque majeur" est plus ténue qu'on ne le pense dans les environnements réels. La veille vulnérabilité efficace en 2026 doit déborder largement les canaux officiels. La dépendance au Patch Tuesday est un risque de gestion qu'il faut désormais adresser explicitement dans les politiques de sécurité. Et la relation entre les chercheurs indépendants et les grands éditeurs est un actif que ces derniers ont tout intérêt à entretenir — non par altruisme, mais parce que les alternatives sont bien pires pour tout le monde.

Pour les RSSI français, cette séquence de mai 2026 est un prétexte concret pour revisiter trois points : la configuration BitLocker de vos appareils mobiles, vos procédures de déploiement de mitigations d'urgence, et vos sources de veille vulnérabilité. Si les trois réponses sont satisfaisantes, vous avez traversé cette vague sans trop de dégâts. Sinon, il y a du travail — autant le faire maintenant, avant la prochaine série.