Microsoft a tenu deux positions opposées en une semaine. C'est ça, la faille.
Pendant que l'industrie refait le procès de la divulgation responsable, une faille qui contourne BitLocker dort toujours sans correctif. Et Microsoft qui a écrit les règles du jeu vient de prouver qu'elle ne les suit que selon son humeur.

Pendant que l'industrie refait le procès de la divulgation responsable, une faille qui contourne BitLocker dort toujours sans correctif. Et l'entreprise qui a écrit les règles du jeu vient de prouver qu'elle ne les suit que selon son humeur.
Reprenons la semaine de Microsoft. Un jour, l'entreprise publie un billet qui qualifie d'« injustifiable » toute divulgation de faille hors de ses canaux et brandit la menace de poursuites pénales via son unité dédiée aux crimes numériques. Quelques jours plus tard, sous les huées de la communauté sécurité, elle explique qu'elle n'a évidemment aucune intention de poursuivre qui que ce soit et que la divulgation coordonnée reste sa boussole. Mêmes faits, deux positions opposées, sept jours d'écart.
Pendant ce temps, l'une des six failles concernées contourne le chiffrement BitLocker de Windows 11 et attend toujours son correctif. On se dispute sur les bonnes manières d'un chercheur pendant qu'une porte de chiffrement reste ouverte.
L'industrie, fidèle à elle-même, a aussitôt rejoué son débat préféré, celui de la divulgation responsable. Le chercheur aurait-il dû patienter. Microsoft a-t-il le droit de menacer. On a pris parti, on s'est indigné, on a ressorti ses pires souvenirs de signalement au MSRC. Et on est passé à côté de ce que la séquence montrait vraiment.
Que s'est-il passé exactement entre Microsoft et le chercheur ?
Reconstituons la séquence, pièces à l'appui. Le 27 mai 2026, le centre de réponse sécurité de Microsoft, le MSRC, publie un billet qui nomme six failles divulguées hors de ses canaux, RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma et MiniPlasma, et pose que les divulgations non coordonnées mettant du code d'exploitation de failles non corrigées entre les mains d'acteurs malveillants ne sont « jamais justifiables ». Le texte précise que son unité dédiée aux crimes numériques continuera de porter des affaires contre ces acteurs et ceux qui les aident, en coordination avec les autorités du monde entier.
Trois à quatre jours plus tard, sous la pression de la communauté, l'entreprise recadre : elle n'aurait « aucune intention d'engager des poursuites contre les personnes qui mènent ou publient des travaux de recherche en sécurité », la voie pénale ne visant que celui qui « enfreint la loi et cause un préjudice réel » à ses clients. Entre les deux déclarations, rien n'a changé dans les faits, sauf le volume des critiques.
Le chercheur, qui signe Nightmare Eclipse, affirme pour sa part que Microsoft lui avait coupé l'accès au compte MSRC dont il se servait pour remonter ces failles, avant de le pousser à la publication. Version contestée, mais elle place au centre du dossier la seule question qui compte vraiment, celle du canal de signalement.
Une entreprise qui change d'avis en une semaine n'a pas de doctrine
Microsoft n'est pas un acteur naïf de la divulgation, il en est l'inventeur. C'est chez lui, au milieu des années 2000, qu'on a troqué le terme orienté de « responsible disclosure », qui fait porter la faute au chercheur, contre « coordinated disclosure », qui décrit un processus à deux. Vingt ans de pratique, une doctrine écrite, des équipes entières qui la font vivre. Le savoir est là, massif, disponible.
Et il n'a pesé à aucun moment. Quand six failles ont embarrassé l'entreprise, ce n'est pas ce savoir qui a pris la parole, ce sont les avocats. Quand la communauté a réagi, ce ne sont pas davantage les avocats, c'est la communication. La position de Microsoft cette semaine-là n'a pas été dictée par ce qu'il sait de la sécurité, elle a été dictée par la dernière personne à avoir crié assez fort. C'est cela que la séquence révèle, et c'est bien plus inquiétant qu'un chercheur grossier. L'une des entreprises les plus matures du secteur, sommée de défendre une ligne, en a changé en sept jours. Ce n'est pas une doctrine, c'est une humeur.

Quelle faille laisse BitLocker ouvert pendant qu'on débat ?
Parmi les six failles, une seule porte un nom qui devrait clore le débat : YellowKey, référencée CVE-2026-45585, contourne le chiffrement BitLocker de Windows 11. C'est la porte restée ouverte, celle qui met en cause la protection au repos des disques d'une entreprise entière si un attaquant obtient un accès physique ou local à la machine.
Trois autres n'ont pas attendu la fin de la discussion. BlueHammer (CVE-2026-33825), RedSun (CVE-2026-41091) et UnDefend (CVE-2026-45498) ont servi à des attaques réelles et sont entrées au catalogue des vulnérabilités activement exploitées de la CISA, l'agence américaine de cybersécurité, celle-là même que Microsoft cite pour reprocher au chercheur d'avoir armé des attaquants. Quatre failles sur six, donc, avec un correctif manquant ou un exploit déjà dans la nature, pendant que l'énergie de l'industrie partait dans un débat de préséance.
Le chercheur Nightmare Eclipse est-il le vrai problème ?
Que les choses soient claires, je n'absous pas Nightmare Eclipse. Publier le code d'exploitation de failles non corrigées, dont trois ont effectivement servi à des attaques réelles avant d'atterrir au catalogue des vulnérabilités exploitées de la CISA, n'a rien d'un acte de salubrité publique. Il y a des victimes au bout, des organisations sans correctif et sans choix.
Mais regardez ce que cet aveu fait à l'argument de Microsoft. Même en accordant que le chercheur a mal agi, rien n'explique qu'une entreprise de cette taille réponde par un réflexe juridique un jour et un démenti le lendemain. La faute supposée du chercheur ne fabrique pas une position cohérente à l'entreprise. Elle révèle seulement qu'elle n'en avait pas.
La vraie panne est dans la tuyauterie, pas dans la morale
Il y avait pourtant un vrai sujet, et personne ne l'a regardé. Le chercheur affirme avoir d'abord signalé ces failles dans les règles, avant que Microsoft ne supprime le compte qui lui servait à les remonter, ne retienne ses primes et n'efface son nom d'un avis de sécurité. Vrai ou faux dans ce cas précis, peu importe. C'est exactement là que se joue la sécurité réelle, dans l'état du canal qui relie ceux qui trouvent les failles à ceux qui les réparent. Bouchez ce canal, et il ne reste au chercheur que le silence ou la publication sauvage. Les deux finissent en zero-day.
Un processus de divulgation n'est pas une politesse réservée aux chercheurs bien élevés. C'est un dispositif de réduction du risque, avec des délais tenus, des accusés de réception, un paiement, une attribution. Microsoft connaît tout cela par cœur. Il a simplement choisi, sous pression, de défendre sa réputation plutôt que de réparer sa tuyauterie.
La vraie question n'a jamais été de savoir si le chercheur a été responsable. Elle est de savoir comment l'entreprise qui a écrit le manuel de la divulgation a pu, en une semaine, oublier qu'elle l'avait écrit. Le 14 juillet, le chercheur promet une nouvelle salve. On verra ce jour-là si Microsoft a retrouvé une colonne vertébrale, ou seulement une nouvelle humeur.
Sources
- Billet de Microsoft (MSRC), « A shared responsibility: protecting customers through coordinated vulnerability disclosure », 27 mai 2026 : microsoft.com.
- Chercheur « Nightmare Eclipse », identifiants des failles et exploitation réelle constatée par la CISA : TechCrunch, 29 mai 2026.
- Rétractation de Microsoft, détail des six failles (dont YellowKey, CVE-2026-45585, visant BitLocker) et des trois entrées au catalogue KEV : Cybersecurity News.
- Recul de Microsoft sur ses menaces juridiques et réaction de la communauté : Windows Central.
- Vulnérabilités activement exploitées : CISA, Known Exploited Vulnerabilities Catalog.
Questions fréquentes
Quelles sont les deux positions opposées tenues par Microsoft ?
Un jour, l'entreprise qualifie d'« injustifiable » toute divulgation hors de ses canaux et évoque des poursuites via son unité dédiée aux crimes numériques. Trois à quatre jours plus tard, sous les critiques, elle assure n'avoir aucune intention de poursuivre les chercheurs et réaffirme la divulgation coordonnée comme boussole.
Quelle faille reste sans correctif pendant ce débat ?
YellowKey, référencée CVE-2026-45585, contourne le chiffrement BitLocker de Windows 11 et attend toujours son correctif, pendant que l'industrie discute des bonnes manières du chercheur.
Quelles sont les six failles divulguées par Nightmare Eclipse ?
Microsoft les nomme RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma et MiniPlasma. Trois d'entre elles, BlueHammer, RedSun et UnDefend, ont servi à des attaques réelles et figurent au catalogue des vulnérabilités activement exploitées de la CISA.
L'article défend-il le chercheur Nightmare Eclipse ?
Non. L'auteur ne l'absout pas : publier le code d'exploitation de failles non corrigées, dont trois ont servi à des attaques réelles, n'a rien d'un acte de salubrité publique. Mais cela n'explique pas l'incohérence de la réponse de Microsoft.
Microsoft a-t-il vraiment renoncé à poursuivre le chercheur ?
Après son billet du 27 mai 2026, l'entreprise a précisé n'avoir aucune intention d'engager des poursuites contre les personnes qui mènent ou publient des travaux de recherche en sécurité, réservant la voie pénale à qui enfreint la loi et cause un préjudice réel. C'est ce revirement qui, en quelques jours, révèle l'absence de doctrine.
Pourquoi Microsoft est-il particulièrement concerné par la divulgation ?
Microsoft en est l'inventeur : c'est chez lui, au milieu des années 2000, qu'on a remplacé « responsible disclosure » par « coordinated disclosure ». Vingt ans de pratique et une doctrine écrite qui n'ont pourtant pas pesé sur sa réaction.
Qu'est-ce que la « tuyauterie » de la divulgation selon l'article ?
C'est le canal qui relie ceux qui trouvent les failles à ceux qui les réparent, avec délais tenus, accusés de réception, primes et attribution. Quand ce canal est bouché (compte supprimé, primes retenues), il ne reste que le silence ou la publication sauvage, qui finissent en zero-day.
Sources & méthodologie
- Microsoft MSRC, A shared responsibility: protecting customers through coordinated vulnerability disclosure (
- CISA, Known Exploited Vulnerabilities (KEV) Catalog

Être en cybersécurité
Une feuille de route cyber en clair, pour tout le monde, pas seulement les experts.
