Le 12 mai 2026, lendemain du Patch Tuesday de mai, deux vulnérabilités zero-day affectant Microsoft Windows ont été publiquement divulguées sans coordination préalable avec l’éditeur. La première, baptisée YellowKey, permet le contournement complet du chiffrement de volume BitLocker sur Windows 11, Windows Server 2022 et Windows Server 2025 (1)(2). La seconde, GreenPlasma, est une élévation de privilèges locale vers SYSTEM exploitant le processus CTFMON (3)(4). Aucun identifiant CVE n’a été attribué à ce jour. Aucun correctif éditeur n’est disponible. Des codes proof-of-concept fonctionnels circulent publiquement sur GitHub depuis la divulgation.

L’événement dépasse le cadre habituel de l’analyse de vulnérabilités pour deux raisons. D’une part, YellowKey met en cause la robustesse réelle d’un mécanisme de sécurité considéré comme structurant dans le paysage Windows depuis plus d’une décennie : la promesse que le chiffrement de volume protège les données en cas d’accès physique non autorisé. D’autre part, ces divulgations s’inscrivent dans une campagne plus large conduite par un chercheur opérant sous les pseudonymes Chaotic Eclipse et Nightmare-Eclipse, dont la motivation déclarée est de dénoncer les pratiques du Microsoft Security Response Center. Cette dimension transforme l’affaire en cas d’école sur les ruptures de confiance dans l’écosystème de la divulgation responsable.

Pour saisir la portée des divulgations YellowKey et GreenPlasma, il faut les replacer dans la chronologie d’une campagne qui débute en avril 2026. Le chercheur, dont les publications laissent entendre qu’il aurait été employé par Microsoft (5), opère sous deux pseudonymes : Chaotic Eclipse pour les analyses publiées sur le blog deadeclipse666 (6), et Nightmare-Eclipse pour les dépôts de code sur GitHub. Sa première publication, datée du 2 avril 2026, divulgue BlueHammer, une élévation de privilèges via Windows Defender. Microsoft attribue ultérieurement à cette vulnérabilité l’identifiant CVE-2026-33825 et publie un correctif au Patch Tuesday d’avril (5)(7). Selon le chercheur, l’exploitation dans la nature de BlueHammer aurait débuté quatre jours avant la publication du correctif.

Le 15 avril 2026, le chercheur publie un second exploit Defender, RedSun. Le mois suivant, dans une publication signée PGP, il affirme que Microsoft a corrigé silencieusement RedSun sans publier d’avis MSRC, sans attribuer de CVE, et sans communication publique malgré une exploitation active. Cette pratique du silent patching constitue le coeur du reproche adressé à l’éditeur.

Une troisième vulnérabilité Defender, UnDefend, complète la trilogie initiale. La motivation déclarée par Chaotic Eclipse est une violation de confiance. Selon ses propres écrits, plusieurs rapports de vulnérabilités antérieurs auraient été rejetés par le MSRC au motif d’une criticité insuffisante, avant d’être tout de même corrigés en interne, sans rétribution ni attribution publique. C’est cette double pratique, combinant minimisation initiale et exploitation discrète des découvertes, qui justifie selon le chercheur le passage à la divulgation publique non coordonnée.

Le chercheur indique maintenir un dead man switch contenant d’autres exploits prêts à être publiés, et annonce explicitement une nouvelle divulgation pour le Patch Tuesday de juin 2026 (1)(2). Ces deux vulnérabilités ne sont pas des découvertes isolées : elles s’inscrivent dans une stratégie de communication par la pression, où chaque divulgation constitue un acte d’escalade calibré pour maximiser l’embarras de l’éditeur tout en augmentant le coût opérationnel de la posture du MSRC.

YellowKey est décrit par son auteur comme la découverte la plus marquante de sa carrière, et il évoque ouvertement la possibilité qu’il s’agisse d’une backdoor (2)(8). Pour évaluer cette qualification, il convient d’examiner le mécanisme avec rigueur.

BitLocker constitue depuis Windows Vista la solution de chiffrement de volume intégrée à Windows. Sur les configurations modernes, en particulier sur Windows 11 où il est activé par défaut sur les machines compatibles, BitLocker s’appuie sur le Trusted Platform Module (TPM) pour le scellement des clés. Le modèle de menace canonique est le suivant : un attaquant disposant d’un accès physique à la machine, ou ayant volé un disque dur, ne peut pas accéder aux données sans la recovery key, sans le PIN si configuré, et sans l’attestation cryptographique du TPM d’origine.

YellowKey rompt ce modèle. La séquence d’attaque, documentée par le chercheur et reproduite indépendamment par Will Dormann, Kevin Beaumont, KevTheHermit et JaGoTu (1)(7), est la suivante :

1. L’attaquant prépare une clé USB sur laquelle il crée un répertoire nommé FsTx à l’intérieur du dossier System Volume Information.
2. Il dépose dans ce répertoire des fichiers spécialement formatés exploitant les bits Transactional NTFS.
3. Il branche la clé USB sur la machine cible et redémarre dans le Windows Recovery Environment (WinRE).
4. Pendant le boot, il maintient la touche CTRL.
5. Au lieu de l’interface de récupération attendue, le système ouvre directement un shell cmd.exe disposant d’un accès complet et déchiffré au volume BitLocker.

Aucune recovery key n’est demandée. Aucune séquence d’unlock n’est exécutée visiblement. Aucune authentification n’apparaît dans le flux. Plus troublant encore, les fichiers déposés sur la clé USB sont automatiquement supprimés après l’exécution, ce qui limite significativement les artefacts forensiques disponibles dans une analyse post-incident (8).

YellowKey affecte Windows 11 ainsi que Windows Server 2022 et Windows Server 2025. Selon les tests publics, Windows 10 n’est pas affecté (2). Le chercheur précise qu’une variante existe permettant d’attaquer la même cible sans clé USB externe, en plaçant les fichiers directement sur la partition EFI du disque cible, bien que cette variante soit moins reproductible selon les tests indépendants (1).

Le 13 mai 2026, dans une seconde publication signée PGP sur deadeclipse666, le chercheur apporte une précision particulièrement préoccupante : la vulnérabilité reste exploitable sur les configurations BitLocker associant TPM et PIN, qui constituaient jusqu’ici la défense de référence contre les attaques par accès physique.

Le proof-of-concept pour cette variante n’a pas été publié, ce qui laisse subsister une incertitude sur la nature exacte du contournement.

GreenPlasma, divulguée simultanément à YellowKey, présente un profil technique différent. Il s’agit d’une élévation de privilèges locale vers SYSTEM ciblant le processus CTFMON, c’est-à-dire ctfmon.exe, composant du Collaborative Translation Framework responsable des fonctionnalités de saisie de texte avancées (3)(9). Ce processus présente la particularité de tourner en SYSTEM dans chaque session interactive Windows, ce qui en fait une cible privilégiée pour les attaques d’élévation.

Le mécanisme d’exploitation, analysé en détail par Het Mehta (4), repose sur la capacité d’un utilisateur non privilégié à créer un memory section object arbitraire dans un directory object writable par SYSTEM, au sein du namespace de l’Object Manager Windows. La manipulation combine plusieurs astuces de registry et de gestion des permissions pour amener CTFMON à interagir avec une section mémoire qu’il considère comme légitime. L’attaquant obtient ainsi le contrôle d’une zone mémoire de confiance, dans laquelle il peut injecter du shellcode ou simuler une DLL malveillante.

Le proof-of-concept publié sur le dépôt GitHub Nightmare-Eclipse/GreenPlasma est volontairement incomplet (3). Le chercheur a retiré la dernière pièce du puzzle, celle qui permettrait d’obtenir un shell SYSTEM complet, présentant la divulgation comme un capture-the-flag à destination de la communauté. Dans son état actuel, le PoC déclenche un prompt UAC et requiert une weaponisation supplémentaire pour devenir totalement silencieux.

GreenPlasma est confirmée fonctionnelle sur Windows 11, Windows Server 2022 et Windows Server 2026 (10). Son impact opérationnel est asymétrique par rapport à YellowKey.

L’élément le plus troublant de l’affaire YellowKey est une observation faite par Chaotic Eclipse et reprise par plusieurs commentateurs : le composant responsable du bypass n’existe que dans l’image WinRE, et nulle part ailleurs, y compris sur Internet (9). Plus étrange encore, un composant portant exactement le même nom existe dans une installation Windows standard, mais ne contient pas les fonctionnalités déclenchant le contournement de BitLocker. Cette asymétrie alimente l’hypothèse d’une fonctionnalité de récupération non documentée, intentionnellement présente dans WinRE pour permettre un déverrouillage en cas de support technique ou de scénarios de récupération avancée, et jamais retirée.

Cette hypothèse mérite d’être examinée sans complaisance, mais aussi sans dramatisation. Plusieurs éléments objectifs nourrissent le soupçon. Le caractère exclusif du composant à l’image WinRE est inhabituel pour un bug logique standard, qui résulterait normalement d’une erreur d’implémentation reproduite dans l’ensemble du code source. L’auto-suppression des artefacts sur la clé USB après exécution ressemble à un comportement délibérément conçu pour limiter les traces, et non à un effet de bord. Le fonctionnement même de l’exploit, qui ouvre un shell avec accès direct au volume sans étape d’authentification visible, évoque davantage une voie de contournement intégrée qu’un effet émergent de bugs combinés.

À l’inverse, plusieurs arguments plaident pour une explication plus prosaïque. L’analyse de Will Dormann démontre que le mécanisme sous-jacent est compatible avec un défaut de gestion du replay transactionnel NTFS, un sous-système complexe et historiquement source de comportements subtils. La capacité de modifier le contenu d’un volume depuis un répertoire situé sur un autre volume, via les bits Transactional NTFS, peut résulter d’une hypothèse implicite incorrecte dans l’isolation des contextes transactionnels. Dans cette lecture, le bypass de BitLocker est un effet de bord d’un bug logique profond, et non une fonctionnalité conçue. Cette interprétation est confortée par la présence, dans l’histoire récente de Windows, de vulnérabilités structurellement comparables, comme celle qui a affecté le bootmgfw.efi signé avec le certificat PCA 2011 et corrigée en juillet 2025 (10).

En l’absence de correctif éditeur, les organisations doivent évaluer leur exposition et déployer les mitigations disponibles. L’évaluation de risque doit distinguer deux profils d’attaque.

YellowKey exige un accès physique préalable à la machine cible. Sont particulièrement exposées les flottes de portables professionnels, les postes de mobilité, les mini-PC déployés dans des environnements à accès non contrôlé, ainsi que les serveurs Windows situés dans des locaux à accès physique partagé ou faiblement supervisé. Le risque concret est celui du vol ciblé : un portable dérobé dans une chambre d’hôtel, un poste laissé sans surveillance dans un open space partagé, un disque dur extrait d’un parc informatique en fin de vie sans procédure de destruction adéquate.

GreenPlasma s’inscrit dans un modèle de menace différent. La vulnérabilité requiert un accès local non privilégié préalable, ce qui suppose une compromission initiale par d’autres moyens. Son impact se manifeste dans la phase post-exploitation, où elle facilite l’élévation vers SYSTEM, prérequis classique pour la latéralisation et le déploiement de charges utiles persistantes.

Mitigations pour YellowKey

• Renforcement de la protection physique des terminaux exposés. Scellement des boîtiers, procédures de destruction sécurisée des supports en fin de vie, sensibilisation des utilisateurs à la mobilité.
• Activation systématique du BitLocker PIN au démarrage. La protection n’est pas garantie selon le chercheur, mais elle élève significativement la barre d’entrée.
• Restriction ou désactivation contrôlée du Windows Recovery Environment via reagentc, lorsqu’une stratégie de récupération alternative est en place.
• Anticipation de la migration vers le certificat CA 2023 et révocation du PCA 2011, dont le retrait est planifié par Microsoft en juin 2026.

Mitigations pour GreenPlasma

• Détection comportementale au niveau EDR sur les créations de section objects suspectes dans le namespace de l’Object Manager Windows.
• Surveillance des manipulations de registry liées à CTFMON et au Collaborative Translation Framework.
• Application stricte du principe de moindre privilège sur les comptes utilisateurs.
• Hardening Windows standard et désactivation des fonctionnalités CTF non nécessaires.

À ces mitigations techniques s’ajoute une dimension organisationnelle souvent sous-estimée. Compte tenu de la couverture médiatique substantielle de l’affaire, les directions générales et les utilisateurs des organisations exposées formuleront des demandes d’éclaircissement aux équipes de sécurité. Préparer une communication interne factuelle, calibrée et alignée sur les éléments publics disponibles, permet d’éviter les réactions improvisées sous pression médiatique.

L’affaire YellowKey et GreenPlasma dépasse, par sa nature et ses ramifications, le simple registre de l’analyse de vulnérabilités. Elle révèle trois lignes de fracture qui méritent d’être nommées.

Première fracture, entre Microsoft et une partie de la communauté de chercheurs sécurité. La pratique du silent patching, dénoncée de longue date par les acteurs de la divulgation responsable, produit aujourd’hui des effets opérationnels concrets : un cycle de divulgations publiques sans coordination, calibré sur le rythme du Patch Tuesday, qui transforme chaque mois en moment de tension sécuritaire pour les administrateurs Windows. Que la motivation déclarée par Chaotic Eclipse soit légitime ou non, le fait que sa stratégie produise des résultats opérationnels visibles, à coût personnel apparemment faible, suggère que d’autres acteurs pourraient adopter la même posture si l’éditeur ne réajuste pas sa politique de communication.

Deuxième fracture, entre la promesse de sécurité affichée du chiffrement de volume et la réalité de son exposition. BitLocker bénéficie d’une réputation de robustesse construite sur deux décennies de discours marketing et de positionnement comme socle de confiance pour les flottes d’entreprise. L’affaire YellowKey ne détruit pas cette robustesse, mais elle en révèle la fragilité conditionnelle : la sécurité du chiffrement dépend non seulement de la solidité de l’algorithme et du scellement TPM, mais aussi de l’intégrité de tous les composants Windows susceptibles d’interagir avec le volume déchiffré, en particulier le Windows Recovery Environment. Cette surface d’attaque, vaste et mal cartographiée, doit désormais entrer dans les modèles de menace des organisations qui s’appuient sur BitLocker.

Troisième fracture, plus profonde, entre la complexité réelle des systèmes Windows modernes et la capacité de leurs éditeurs à en garantir l’audit complet. Le composant WinRE responsable de YellowKey, qu’il s’agisse d’un bug logique ou d’une fonctionnalité non documentée, est resté inaperçu pendant une durée indéterminée. Sa découverte tardive interroge la qualité des audits internes, l’efficacité des programmes de bug bounty, et la robustesse des processus de revue de code sur les composants historiques d’un système d’exploitation qui agrège des décennies de strates logicielles. Cette interrogation ne concerne pas seulement Microsoft : elle s’applique à l’ensemble des éditeurs maintenant des systèmes d’exploitation matures, dont la complexité a depuis longtemps dépassé la capacité d’analyse exhaustive d’une équipe humaine.

L’annonce par Chaotic Eclipse d’une nouvelle divulgation pour le Patch Tuesday de juin 2026 doit être prise au sérieux. Selon ses propres antécédents, le chercheur n’a jamais failli à ses annonces. Les semaines à venir diront si Microsoft choisit de modifier sa doctrine de communication, si la communauté de chercheurs durcit ou relâche sa pression, et si la chaîne de confiance Windows résiste à cette épreuve sans concession structurelle. Quel que soit l’issue, l’affaire YellowKey aura constitué un point de bascule documenté dans l’histoire récente de la sécurité des systèmes d’exploitation grand public.