En six semaines, un chercheur anonyme a publié six exploits zero-day fonctionnels pour Windows. Fin mai 2026, GitHub lui a fermé son compte ; quelques jours plus tard, GitLab a suspendu un miroir. Or GitHub appartient à Microsoft, l'éditeur dont les produits étaient visés.
L'affaire dépasse le fait divers. Elle pose une question simple et inconfortable : que vaut l'indépendance d'une plateforme d'hébergement de code quand elle arbitre une recherche de sécurité dirigée contre sa maison mère, et quels recours reste-t-il au chercheur qui se fait fermer la porte ?
Un chercheur anonyme contre l'éditeur de Windows
Son pseudonyme : Nightmare-Eclipse, et auparavant Chaotic Eclipse ou Dead Eclipse. Aucune identité publique, aucune affiliation institutionnelle. À partir du 2 avril 2026, il commence à publier du code d'exploitation complet, ou "proof of concept" (PoC), pour des failles Windows non corrigées. Ce jour-là sort BlueHammer, un exploit d'élévation de privilèges qui donne les droits SYSTEM.
Le rythme devient une partie du message : de nouveaux outils apparaissent quelques heures après les correctifs Microsoft. Selon le récit dominant dans la presse spécialisée, il s'agit d'une protestation. Le chercheur affirme avoir signalé ces vulnérabilités au Microsoft Security Response Center (MSRC), s'être heurté à un traitement qu'il juge inacceptable et n'avoir rien perçu du programme de primes aux bogues. Lui seul l'affirme ; Microsoft n'a pas confirmé cette version des faits.
Six exploits, six semaines
Le lot se lit comme une chaîne, pas comme six curiosités séparées. BlueHammer (CVE-2026-33825) et RedSun (CVE-2026-41091) permettent tous deux de passer d'un compte ordinaire à SYSTEM ; UnDefend (CVE-2026-45498) désactive progressivement Windows Defender pour rendre l'intrusion plus discrète. Les trois premiers ont été corrigés : BlueHammer dans la mise à jour d'avril 2026, RedSun et UnDefend lors d'une mise à jour hors cycle le 21 mai 2026.
Les trois autres visaient des mécanismes plus profondément enfouis dans Windows : GreenPlasma exploite le service CTFMon, MiniPlasma le pilote Cloud Filter, tous deux pour obtenir des privilèges élevés. YellowKey, lui, contourne le chiffrement de disque BitLocker, ce qui remet en cause l'hypothèse selon laquelle un portable perdu mais chiffré reste hors de portée.
Ces trois derniers étaient encore en cours de correction fin mai 2026, selon les analyses publiées alors : il fallait les considérer comme ouverts.
Ce qui a réellement été exploité
C'est le point où la prudence s'impose, car il détermine la gravité réelle de l'affaire. Les équipes d'intervention en sécurité ont confirmé BlueHammer, RedSun et UnDefend dans une intrusion réelle. BlueHammer a été observé à l'oeuvre à partir du 10 avril environ. RedSun et UnDefend, eux, ont été retrouvés sur une machine compromise d'abord par un compte VPN SSL détourné.
Autrement dit : un seul hôte documenté, dont l'entrée s'est faite par un identifiant volé, pas une vague d'attaques indépendantes réparties sur la planète. La nuance compte. Elle ne minore pas le danger - un point d'entrée volé plus une élévation de privilèges, c'est aujourd'hui la recette standard d'une compromission totale - mais elle interdit d'écrire que les trois exploits ont été "massivement utilisés". Ce que l'on peut dire, c'est que dès qu'un PoC fonctionnel est public, les attaquants l'adoptent vite, et que le trio a été retrouvé à l'oeuvre.
"Violating coordinated vulnerability best practices"
Face aux publications, Microsoft a réagi dans ses avis de sécurité, à propos de YellowKey : "The proof of concept for this vulnerability has been made public, violating coordinated vulnerability best practices." L'éditeur défend une règle de la profession : prévenir en privé, laisser un délai au correctif, publier ensuite. Sur le fond, l'argument est solide. Un exploit public pour une faille non corrigée donne simultanément le code aux défenseurs et aux attaquants, et Windows équipe une part écrasante des parcs informatiques.
Le chercheur, lui, a accusé Microsoft de lui avoir supprimé son compte MSRC - celui qui servait à déposer ses signalements - et de ne pas avoir honoré les primes promises au titre du programme de récompenses. Dans un message cité par Cybernews, il a écrit, en anglais : "They knew this would happen, and they still stabbed me in the back anyway. This is their decision, not mine." Traduction : ils savaient que cela arriverait, et ils m'ont quand même poignardé dans le dos. C'est leur décision, pas la mienne. La presse spécialisée a aussi relayé la formule "homeless with nothing" - sans domicile, sans rien - pour décrire ce que Microsoft lui aurait laissé.
Le ton n'a pas toujours été à la plainte. Le 14 juillet 2026, le chercheur a menacé Microsoft de réduire "vos os en miettes", et promis une publication plus importante à cette date. Ces messages font partie du dossier, et ils expliquent une partie des réticences : entre un éditeur qui communique mal et un chercheur qui profère des menaces, la communauté s'est divisée.
Le doute demeure, et il est légitime, sur la chronologie exacte des signalements privés. Le chercheur affirme avoir suivi les canaux officiels ; Microsoft soutient que les bonnes pratiques de divulgation coordonnée n'ont pas été respectées. Aucune des deux parties n'a publié d'élément permettant de trancher.
GitLab suspend le miroir, GitHub ne s'explique pas
GitHub a supprimé le compte du chercheur vers le 23 mai 2026, sans détailler publiquement le motif exact de la décision. Le chercheur a immédiatement reconstruit son dépôt ailleurs : la page GitLab servait de miroir rapide des six outils, ce qui prolongeait leur diffusion malgré le bannissement initial.
Ce miroir a été suspendu le 26 mai 2026, quelques jours après GitHub. GitLab n'a pas exposé de motif public, et il n'y a pas de raison d'affirmer que les deux plateformes ont agi au même titre. Ce qui est certain, c'est que le remède évident - aller voir ailleurs - n'a tenu que trois jours.
Un règlement à la discrétion de la plateforme
La mécanique du bannissement est, elle, parfaitement documentée, et c'est peut-être l'enseignement le plus utile. Les règles d'usage acceptable de GitHub réservent à la plateforme une discrétion complète : elle peut suspendre un compte, le résilier ou retirer du contenu sans avoir à motiver publiquement sa décision. Le recours existe, mais il passe par un formulaire d'appel et une procédure interne à GitHub. Pas de tiers arbitre, pas de délai garanti, aucune obligation de publier un avis.
GitHub a par ailleurs fait évoluer sa politique pour autoriser le retrait de code d'exploitation lorsqu'il est utilisé dans des attaques actives. Le principe se défend. Sa mise en oeuvre, elle, reste discrétionnaire : l'interprétation des règles et l'arbitrage des litiges se font, selon les textes, "en faveur de la protection de l'ensemble des utilisateurs".
Le problème n'est donc pas l'illégalité - publier un exploit est, en soi, licite aux États-Unis, où le débat juridique porte surtout sur le contournement de mesures techniques et sur les lois anti-fraude informatique, plus floues. Le problème est l'asymétrie : Microsoft est à la fois la partie lésée, le juge et le propriétaire du tribunal.
Autre épisode, qui relativise l'affaire : fin juin 2026, un chercheur signant "bikini" a publié sur GitHub un dépôt nommé "Exploitarium", regroupant plus de trente PoC pour des projets open source (noyau Linux, libssh2, FFmpeg, 7-Zip, PHP, VLC et d'autres), sans divulgation coordonnée préalable. Le dépôt était public au moment des articles qui en rendaient compte, et une des failles, CVE-2026-55200 dans libssh2, a été jugée sévère et exploitée. Deux dossiers très comparables, deux traitements perçus comme différents : c'est le signe que l'application des règles dépend de l'urgence, de la visibilité et de la pression médiatique, pas d'un barème stable.
Ce que ça change pour les utilisateurs de Windows
L'angle pratique reste le même, quel que soit le camp choisi. Vérifier d'abord que chaque machine Windows a bien reçu la mise à jour d'avril 2026 (BlueHammer) et celle du 21 mai 2026 (RedSun et UnDefend) : deux de ces trois failles ont été exploitées, donc une machine non à jour n'est pas un risque théorique. Le portable qui ne rentre jamais au bureau est précisément celui qu'on oublie.
Ensuite, pour les trois failles encore ouvertes fin mai 2026, on ne corrige pas mais on réduit la casse. Exiger un TPM avec code PIN au démarrage sur les portables, pour que le disque ne se déverrouille pas tout seul ; conserver les clés de récupération dans l'outil de gestion et non sur un papier collé à l'écran ; s'assurer qu'un appareil perdu peut être effacé à distance. Et retenir la leçon de fond du dossier : BlueHammer s'est servi des privilèges de Defender contre Defender lui-même, UnDefend a éteint sa surveillance par étapes. Un poste dont toute la défense repose sur "Defender est activé" est exactement ce que ce type de campagne traverse.
Reste la question de départ. Qu'une plateforme détenue par un éditeur puisse décider ce qui reste en ligne au sujet des produits de cet éditeur n'est pas un scandale en soi : c'est une situation de conflit d'intérêts qu'aucune charte interne ne neutralise. Ce que l'affaire a montré, c'est qu'après la suppression du compte GitHub puis du miroir GitLab, le code était déjà partout, les correctifs étaient en cours, et le chercheur a continué à publier d'autres outils sous le même pseudonyme. Le bannissement n'a rien protégé. Il a seulement rendu visible le déséquilibre entre celui qui cherche la faille et celui qui possède le terrain où on en parle.
