Admin Insights for Windows 365 is a feature, currently in public preview, that surfaces prioritized health and performance signals for your Cloud PCs directly in the Microsoft Intune admin center. Instead of hunting through separate reports, you see dynamically generated insight cards on a single overview page. The feature covers connectivity, provisioning, performance, and utilization issues. It requires Windows 365 Enterprise or Windows 365 Flex licensing and appropriate read permissions.
Quelques jours après la publication publique du PoC YellowKey, Microsoft réagit enfin en publiant des mesures de mitigation temporaires pour limiter les risques d’exploitation de cette faille BitLocker désormais suivie sous l’identifiant CVE-2026-45585.
YellowKey exploite WinRE pour contourner BitLocker
Comme nous l’évoquions dans notre précédent article, YellowKey permettrait à un attaquant disposant d’un accès physique :
de démarrer dans WinRE
d’utiliser des fichiers spécialement préparés
puis d’obtenir un accès aux volumes BitLocker sans clé de récupération
Le PoC publié par le chercheur Nightmare-Eclipse (également connu sous le nom Chaotic Eclipse) exploite notamment des mécanismes Transactional NTFS et certains comportements du système de récupération Windows.
Microsoft confirme désormais officiellement le problème et attribue le CVE-2026-45585 à cette faille.
Microsoft recommande de désactiver autofstx.exe
Le point technique le plus intéressant concerne la mitigation proposée par Microsoft.
La firme recommande de supprimer l’entrée autofstx.exe de la clé de registre BootExecute utilisée par le Session Manager Windows.
Concrètement, autofstx.exe correspond au composant FsTx Auto Recovery Utility utilisé dans WinRE pour rejouer certaines transactions NTFS pendant les opérations de récupération système.
Selon plusieurs analyses sécurité, YellowKey exploiterait justement ce mécanisme Transactional NTFS afin :
de manipuler certains fichiers système
de supprimer winpeshl.ini
puis d’obtenir une invite de commande non restreinte dans WinRE
En désactivant autofstx.exe, Microsoft bloque donc une partie importante de la chaîne d’exploitation.
Microsoft recommande aussi TPM + PIN
Autre point important : Microsoft recommande désormais explicitement d’utiliser BitLocker avec une configuration TPM + PIN plutôt que TPM seul.
Aujourd’hui, beaucoup de PC Windows 11 utilisent BitLocker en mode TPM-only :
le TPM déverrouille automatiquement le disque au boot
aucun code PIN n’est demandé
l’expérience utilisateur reste transparente
Le problème est que ce mode devient plus vulnérable aux attaques physiques ou aux manipulations du processus de démarrage.
Avec TPM + PIN :
un code doit être saisi avant le boot Windows
le TPM seul ne suffit plus
l’attaque YellowKey devient beaucoup plus difficile à exploiter
Microsoft recommande aussi :
de protéger l’UEFI/BIOS par mot de passe
de verrouiller l’ordre de boot
de limiter le démarrage USB
de surveiller les accès WinRE inhabituels
Pourquoi Microsoft ne publie pas encore de correctif
Pour le moment, aucun patch complet n’est disponible.
Microsoft explique travailler sur une mise à jour de sécurité future mais préfère publier immédiatement des mitigations afin de réduire les risques pendant la période de vulnérabilité publique.
Le contexte est compliqué car :
le PoC a déjà été publié
plusieurs chercheurs ont reproduit la faille
les exploitations pourraient rapidement apparaître
BitLocker est activé par défaut sur beaucoup de PC Windows 11
Microsoft précise toutefois qu’aucune exploitation active massive n’a encore été observée pour le moment.
Une série de zero-days Windows publiés publiquement
YellowKey s’inscrit dans une série inhabituelle de divulgations publiques réalisées par Nightmare-Eclipse depuis plusieurs semaines :
Le chercheur accuse Microsoft d’avoir ignoré certains rapports de vulnérabilités, ce qui aurait conduit à ces divulgations publiques après Patch Tuesday.
Pour approfondir ces sujets, consultez ces actualités :
Je suis tombé sur un accessoire à moins de 10 euros qui ne paie pas de mine, et que j'utilise pourtant tous les jours depuis que je l'ai reçu. C'est un simple autocollant. Un carré de vinyle transparent d'environ 8 cm de côté, qui liste les raccourcis clavier essentiels de macOS et se colle dans le coin de votre MacBook.
L'idée est bête comme chou. Au lieu d'aller chercher sur Google "comment faire une capture d'écran sur Mac" pour la centième fois, vous baissez les yeux vers le coin de votre clavier et c'est écrit. Cmd+Maj+4 pour capturer une zone de l'écran, Cmd+Espace pour ouvrir la recherche Spotlight, Cmd+Option+Échap pour forcer une application à quitter. Tout est regroupé sur un petit carré.
La pose se fait en deux minutes. Le vinyle est transparent, donc une fois collé sur la coque ou près du trackpad, ça reste discret et ça ne jure pas avec le design du Mac. Synerlogic conseille de dépoussiérer la surface et d'appliquer l'autocollant progressivement pour éviter les bulles d'air (évidemment moi je me suis précipité, donc ça a laissé quelques bulles, mais l'autocollant se repositionne sans mal pour les retirer). Bon point en plus : la colle n'est pas définitive. Vous pouvez retirer l'autocollant sans laisser la moindre trace, ce qui est cool si vous revendez la machine plus tard.
Le vrai intérêt, c'est pour les gens qui débutent sur Mac. Quand on arrive de Windows, les raccourcis changent tous, et c'est un des trucs les plus agaçants de la transition. Avec la liste sous les yeux, l'apprentissage se fait tout seul, sans effort. Au bout de quelques semaines, vous connaissez les raccourcis par cœur et l'autocollant devient un filet de sécurité pour les commandes que vous utilisez moins souvent.
Et si vous êtes sous Windows, Synerlogic décline exactement le même autocollant en version Windows, avec les raccourcis Windows qui vont bien pour gagner en productivité.
Alors oui, ça reste un autocollant. Il liste les raccourcis classiques, pas les combinaisons exotiques d'un développeur ou d'un monteur vidéo. Et si vous maîtrisez déjà votre Mac sur le bout des doigts, il ne vous apprendra rien. Mais à moins de 10 euros, franchement n'hésitez pas.
Disponible ici sur Amazon pour macOS
, et
ici pour Windows
!
Windows Autopatch in the Intune admin center now includes an updated Secure Boot status report that provides device-level visibility into certificate readiness ahead of the 2026 expiry deadline. The report shows which devices have Secure Boot enabled, whether their certificates are up to date, and whether automatic or manual deployment applies. New columns for trust configuration, confidence level, and alerts help you make targeted decisions instead of broad deployments.
The May 2026 cumulative update KB5089549 added a new C:\Windows\SecureBoot\ExampleRolloutScripts folder containing seven PowerShell scripts. These scripts are part of Microsoft's sample toolkit for managing Secure Boot certificate migration across enterprise environments. This article explains what each script does, how to run it, and its limitations.
Microsoft is pulling the plug on SMS-based two-factor authentication because it has become a leading source of fraud, replacing it with passkeys and verified email.
Microsoft reconnaît officiellement que la mise à jour de sécurité KB5089549 pour Windows 11 peut échouer à l’installation avec l’erreur 0x800f0922 sur certains PC.
Le problème touche principalement Windows 11 25H2 après le Patch Tuesday de mai 2026 et semble lié aux nouvelles mises à jour du Secure Boot 2023 intégrées dans cette cumulative.
L’erreur 0x800f0922 revient encore sur Windows Update
L’erreur 0x800f0922 n’est pas nouvelle sous Windows Update. Elle apparaît généralement lorsque Windows rencontre un problème pendant :
Avec KB5089549, Microsoft confirme que certains systèmes peuvent :
échouer pendant l’installation
annuler la mise à jour
revenir automatiquement à la version précédente
afficher 0x800f0922 dans l’historique Windows Update
Dans certains cas, plusieurs redémarrages successifs peuvent également survenir avant l’échec final.
Le problème semble lié au Secure Boot 2023
Cette mise à jour contient notamment les nouveaux certificats Secure Boot 2023 qui remplacent progressivement les anciens certificats UEFI de 2011 arrivant à expiration en juin 2026.
Or, la mise à jour de ces composants sensibles du démarrage Windows nécessite :
des modifications UEFI
des mises à jour de certificats
des opérations sur la partition EFI
des vérifications TPM/Secure Boot
Sur certaines configurations, ces opérations échoueraient pendant la phase d’installation.
Microsoft précise que le problème touche principalement les systèmes utilisant certaines configurations TPM ou Secure Boot spécifiques.
Techniquement, pourquoi l’erreur 0x800f0922 se produit ?
Avec KB5089549, Microsoft déploie notamment les nouveaux certificats Secure Boot 2023 ainsi que des modifications des fichiers de boot. Or, ces opérations nécessitent d’écrire de nouveaux fichiers dans la partition EFI.
Le souci est que beaucoup de PC disposent d’une partition EFI très petite :
100 Mo
260 Mo
parfois moins sur certaines anciennes installations OEM
Et cette partition contient déjà :
les fichiers de boot Windows
les certificats Secure Boot
les fichiers BitLocker
des composants OEM
parfois plusieurs anciens chargeurs EFI
Microsoft explique que les systèmes disposant de 10 Mo ou moins d’espace libre dans l’ESP sont particulièrement touchés.
Pendant l’installation :
Windows télécharge la cumulative
prépare les nouveaux fichiers de boot
commence la phase de redémarrage
tente de mettre à jour les composants EFI/Secure Boot
Dans les journaux, plusieurs erreurs reviennent fréquemment :
SpaceCheck: Insufficient free space
ServicingBootFiles failed. Error = 0x70
SpaceCheck: <value> used by third-party/OEM files outside of Microsoft boot directories
Le dernier message est particulièrement intéressant car il montre que certains constructeurs OEM ajoutent leurs propres fichiers EFI dans la partition système, réduisant encore davantage l’espace disponible.
Cela explique aussi pourquoi le problème est difficile à corriger globalement :
chaque constructeur utilise un firmware différent
les tailles de partition EFI varient énormément
certains OEM ajoutent beaucoup de composants personnalisés
certaines anciennes installations Windows ont des partitions EFI sous-dimensionnées
Microsoft recommande actuellement d’utiliser un Known Issue Rollback (KIR) côté entreprise afin de désactiver temporairement le changement responsable du problème.
KB5089549 avait déjà corrigé les problèmes BitLocker
Le contexte est un peu ironique car KB5089549 corrige justement un autre problème important introduit par les précédentes mises à jour Windows 11.
Les mises à jour KB5083769 et KB5082052 provoquaient chez certains utilisateurs des écrans de récupération BitLocker après installation des updates mensuels.
Microsoft avait alors expliqué que :
certains profils PCR7/TPM
certaines configurations Secure Boot
et certaines chaînes de démarrage UEFI
entraient en conflit avec les nouvelles mises à jour de sécurité du démarrage Windows.
KB5089549 était censée corriger définitivement ces problèmes BitLocker sur Windows 11 25H2.
Mais visiblement, la mise à jour introduit maintenant de nouveaux soucis d’installation chez certains utilisateurs.
Microsoft travaille sur un correctif
Pour le moment, Microsoft n’a pas publié de solution définitive.
La firme indique enquêter sur :
les échecs 0x800f0922
les problèmes de boot liés au Secure Boot 2023
certaines incompatibilités TPM/UEFI
Un futur correctif devrait être publié dans une prochaine cumulative ou via Known Issue Rollback (KIR).
En attendant, Microsoft recommande surtout :
de laisser plusieurs tentatives d’installation
de vérifier que le BIOS/UEFI est à jour
de ne pas désactiver Secure Boot
d’éviter les modifications manuelles de la partition EFI
Pourquoi cette transition Secure Boot devient compliquée
Depuis plusieurs mois, Microsoft déploie progressivement une énorme transition de sécurité autour du démarrage Windows :
nouveaux certificats Secure Boot 2023
remplacement des certificats 2011
nouvelles chaînes de confiance UEFI
renforcement TPM
nouvelles politiques de démarrage sécurisé
Le problème est que Windows doit rester compatible avec :
des millions de PC
des BIOS OEM très différents
des firmwares parfois anciens
des configurations TPM variées
Résultat : la moindre modification du processus de boot peut provoquer :
Microsoft veut en finir avec les problèmes de pilotes sous Windows avec une nouveauté intégrée à Windows Update nommée "Cloud-Initiated Driver Recovery".
Windows 11's special Copilot Key has not been the popular hit that Microsoft was hoping it would be, and has now confirmed plans to let users remap the button back to its old functionality.
Un nouveau zero-day Windows baptisé « MiniPlasma » vient d’être publié publiquement avec un exploit Proof of Concept (PoC). La vulnérabilité permettrait à un utilisateur disposant déjà d’un accès local limité d’obtenir les privilèges SYSTEM, soit le niveau d’accès le plus élevé sous Windows.
Cette nouvelle faille a été révélée par le chercheur « Chaotic Eclipse », déjà à l’origine des récents PoC BlueHammer, RedSun, UnDefend et YellowKey visant différentes protections de Windows et BitLocker.
MiniPlasma exploite le Planificateur de tâches Windows
Selon les premières analyses, MiniPlasma cible le service Windows Task Scheduler (Planificateur de tâches).
Le PoC exploiterait une mauvaise gestion des liens symboliques et des permissions de certains fichiers utilisés pendant l’exécution de tâches système. L’attaquant pourrait alors détourner ce mécanisme pour exécuter du code avec les privilèges SYSTEM.
Concrètement, un utilisateur standard pourrait :
créer certains liens symboliques
manipuler des chemins de fichiers spécifiques
déclencher une tâche système
obtenir une élévation de privilèges complète
Le PoC publié permettrait d’obtenir un shell SYSTEM en quelques secondes sur certaines versions de Windows.
Une faille locale mais très dangereuse
MiniPlasma ne permet pas une compromission à distance directe via Internet. L’attaquant doit déjà disposer :
d’un accès local
ou d’un malware exécuté avec des droits utilisateur classiques
Mais ce type de faille reste extrêmement critique dans les chaînes d’attaque modernes.
En pratique, les cybercriminels utilisent souvent ce genre d’élévation de privilèges après :
un phishing
une exécution de malware
une faille navigateur
une compromission RDP
une infection initiale limitée
L’objectif est ensuite d’obtenir les privilèges SYSTEM afin de :
désactiver Microsoft Defender
contourner certaines protections
installer des rootkits
accéder à davantage de données
persister dans le système
Une ancienne faille Google Project Zero toujours exploitable ?
Selon le chercheur Chaotic Eclipse, MiniPlasma ne serait pas une vulnérabilité entièrement nouvelle. Le problème toucherait en réalité le pilote système cldflt.sys, utilisé par Windows pour les fonctionnalités Cloud Filter liées notamment à OneDrive et aux fichiers à la demande.
La faille se situerait plus précisément dans la routine HsmOsBlockPlaceholderAccess.
Le plus surprenant est que cette vulnérabilité avait déjà été signalée à Microsoft en septembre 2020 par le chercheur James Forshaw de Google Project Zero. À l’époque, elle avait reçu l’identifiant CVE-2020-17103 et Microsoft avait annoncé un correctif déployé en décembre 2020.
Mais selon Chaotic Eclipse, le problème serait toujours exploitable aujourd’hui.
Le chercheur affirme que :
soit le correctif initial n’a jamais complètement résolu le problème
soit une modification ultérieure de Windows aurait réintroduit silencieusement la faille
Encore plus inquiétant, il explique que le PoC original publié par Google fonctionnerait toujours sans modification majeure.
BleepingComputer a d’ailleurs testé l’exploit sur un système Windows 11 Pro entièrement à jour avec les mises à jour Patch Tuesday de mai 2026.
Dans leur test :
un simple compte utilisateur standard a été utilisé
l’exploit a été exécuté localement
une invite de commande avec les privilèges SYSTEM a été obtenue immédiatement
Cela montre que la vulnérabilité reste exploitable même sur des systèmes Windows 11 récents et entièrement patchés.
Un nouveau PoC publié avant correctif Microsoft
Comme pour les précédentes vulnérabilités publiées par Chaotic Eclipse, Microsoft n’aurait pas encore publié de correctif officiel au moment de la publication du PoC.
Le chercheur accuse une nouvelle fois Microsoft d’avoir ignoré ou retardé le traitement de certains rapports de sécurité.
Ces derniers mois, plusieurs PoC similaires ont été publiés publiquement avant correction :
BlueHammer
RedSun
UnDefend
YellowKey
GreenPlasma
Certaines de ces vulnérabilités ont finalement été corrigées discrètement dans les Patch Tuesday suivants après médiatisation.
Windows reste vulnérable aux élévations de privilèges locales lorsque certains composants historiques du système sont mal protégés.
Le problème est que Windows conserve encore énormément de mécanismes hérités pour :
la compatibilité logicielle
les services système
les tâches planifiées
les composants Win32 historiques
Le Planificateur de tâches Windows est notamment une cible régulière des chercheurs sécurité car il fonctionne avec des privilèges très élevés et interagit avec de nombreux composants système sensibles.
Microsoft pourrait corriger discrètement la faille
Pour le moment, Microsoft n’a pas communiqué officiellement sur MiniPlasma.
Mais au vu des précédents cas récents, il est probable que :
un correctif soit préparé
une CVE soit attribuée plus tard
la correction arrive dans un futur Patch Tuesday
Les administrateurs système et utilisateurs sensibles doivent donc :
Si vous tournez sur un Windows 11 à jour, sachez qu'il existe une faille qui permet à un programme local spécialement conçu de grimper tranquillou jusqu'au compte SYSTEM. Pour rappel, c'est le compte tout-puissant de la machine, c'est à dire celui qui passe même au-dessus de l'administrateur ! Et cette faille elle s'appelle MiniPlasma, et elle vient d'être balancée en public sur GitHub par un chercheur planqué derrière le pseudo Nightmare-Eclipse.
Et le plus gênaaaaant dans l'histoire, c'est que Microsoft était censé avoir bouché ce trou depuis 2020, dans cette
CVE-2020-17103
, après un signalement de James Forshaw, le chercheur du Project Zero de Google.
Le bug vit sa life dans cldflt.sys, le pilote Cloud Files de Windows. Ce truc c'est un composant système livré d'office avec l'OS, qui est principalement utilisé par OneDrive mais aussi par d'autres stockages cloud. Et bien sûr, il reste présent sur la machine même si vous ne touchez jamais à OneDrive.
Du coup, en passant par une API non documentée baptisée CfAbortHydration, l'exploit crée des clés de registre là où il ne devrait pas, et s'en sert pour détourner un chemin d'exécution privilégié, ce qui finit par lui ouvrir les droits SYSTEM.
Le code de démo est dispo sur le
dépôt GitHub du projet
, écrit en C#, et il lance directement un cmd.exe en SYSTEM quand ça fonctionne. Parce que oui, ça ne marche pas à tous les coups puisque c'est une race condition. Le taux de réussite varie donc d'une machine à l'autre.
Le PoC en action : à gauche, un compte « user » standard lance l'exploit (« Exploit succeeded ») et à droite, le shell obtenu où whoami renvoie nt authoritysystem.
Maintenant, le truc qui fait vraiment mal au cul, c'est que la fameuse faille patchée par Microsoft est donc toujours vulnérable 6 ans après sa détection. Personne ne vérifie chez krosoft ??? C'est dingue !
Selon le chercheur, c'est exactement la même faiblesse qu'à l'époque. Reste à savoir pourquoi ça leur a échappé. Le patch n'a peut-être jamais corrigé la racine du problème, ou il a sauté quelque part en cours de route, j'en sais rien... Faudra analyser le code de Windows et de ses MAJ au fil du temps pour comprendre où ça a merdé.
Du coup, votre machine peut avoir avalé tous les Patch Tuesday et rester quand même exposée à une élévation de privilèges locale dès qu'un attaquant (ou un malware) arrive à exécuter du code dessus.
Nightmare-Eclipse n'en est d'ailleurs pas à son coup d'essai puisque le chercheur enchaîne les divulgations publiques de 0-days Windows depuis quelques semaines, du contournement BitLocker au déni de service sur Defender en passant par plusieurs élévations de privilèges, toujours avec le PoC qui va bien et zéro divulgation coordonnée.
Et y'a pas de "on prévient Microsoft et on attend gentiment 90 jours" ici. Il balance tout car il est a ras-le-bol de la lenteur de Microsoft. C'est violent, dangereux et clairement discutable côté éthique, mais ça met une grosse pression pour corriger au plus vite. Maintenant pour nous tous, ça signifie surtout qu'un PoC public et fonctionnel, ce sont des malwares qui vont vite l'intégrer.
Côté protection, il n'y a pas de correctif officiel ni la moindre déclaration de Microsoft et ucune mitigation validée par l'éditeur non plus. Puis pour un particulier, pas de moyen simple de savoir après coup si la machine a été touchée.
La bonne nouvelle (relative c'est vraie), c'est que l'attaque est purement locale, donc il faut déjà pouvoir exécuter du code sur l'ordi pour en profiter. Votre vraie défense, c'est donc votre hygiène tech habituelle, à savoir ne pas lancer le premier binaire douteux venu, se méfier des cracks et autres pièces jointes, et côté admins, une surveillance EDR des élévations de privilèges inattendues vaut mieux qu'une règle maison non testée.
Un développeur connu sous le pseudo
ThroatyMumbo
a réussi à porter Windows CE 2.11, un Windows allégé que Microsoft avait sorti à la fin des années 90 pour les petits assistants personnels et certains routeurs, sur une vraie console Nintendo 64
On ne parle pas d'un émulateur ici, mais bien d'une N64 qui démarre sur un vrai bureau Windows, avec sa barre des tâches, son explorateur de fichiers et la possibilité de lancer des programmes CE.
Pour bien comprendre le délire, il faut savoir que la N64 et Windows n'ont pas grand chose en commun. La console utilise un processeur MIPS et un système maison signé Nintendo. Windows CE, c'est l'inverse : un système Microsoft conçu pour tourner sur des appareils embarqués comme les assistants personnels.
Sauf que les deux mondes se croisent sur deux points clés. Windows CE tournait déjà sur des puces MIPS à l'époque, et il était conçu pour vivre avec à peine 1 Mo de RAM, ce qui correspond pile aux capacités de la N64. ThroatyMumbo s'est inspiré de l'IBM Workpad Z50, un ancien assistant qui tournait sous CE sur du MIPS, pour se dire que le portage était techniquement faisable.
Côté méthode, le kernel Windows CE d'origine n'est pas modifié. Tout le travail est dans la couche d'abstraction matérielle, la fameuse HAL, qui sert d'interface entre le système et le matériel. Le développeur a écrit la sienne de zéro pour la N64 : démarrage, gestion des interruptions, du timing, de l'affichage.
Le contrôleur N64 devient une souris (le bouton A pour clic gauche, le B pour clic droit, logique). L'EverDrive-64 X7, une cartouche qui fait office de lecteur SD, sert de disque dur. Et le son passe par la puce audio d'origine de la console.
Ce qui marche est franchement bluffant : déplacer les fenêtres, fermer une boîte de dialogue, naviguer dans les fichiers, lancer des exécutables CE tiers, et même afficher une démo 3D qui utilise la puce graphique de la console. Ce qui ne marche pas : pas de clavier physique, pas de réseau, et il faut le SDK Windows CE 2.11 de Microsoft, qui n'est plus commercialisé depuis longtemps.
Aucune utilité concrète, évidemment. Personne ne va remplacer Mario Kart 64 par Word pour Windows CE. Mais c'est rigolo, et permet de prouver qu'on peut faire un truc complètement absurde, juste parce que c'est techniquement intéressant.
Une nouvelle faille de sécurité visant BitLocker inquiète actuellement la communauté cybersécurité. Un chercheur a publié un exploit Proof of Concept (PoC) baptisé « YellowKey » qui permettrait de contourner la protection BitLocker sur certains systèmes Windows 11 et Windows Server.
Le problème est particulièrement sensible car BitLocker est aujourd’hui activé par défaut sur de nombreux PC Windows 11 afin de protéger les données en cas de vol ou d’accès physique au disque.
des fichiers spécifiques sont copiés sur une clé USB
le PC démarre dans l’environnement WinRE
l’exploit déclenche ensuite une invite de commande élevée
le disque BitLocker devient accessible sans demander la clé de récupération
Le chercheur affirme que la faille fonctionne notamment sur :
Windows 11
Windows Server 2022
Windows Server 2025
Windows 10 ne semblerait pas concerné selon les premiers tests.
Une attaque nécessitant un accès physique
Le point important est que cette vulnérabilité nécessite un accès physique à la machine.
L’attaquant doit pouvoir :
accéder au PC
brancher une clé USB
démarrer dans l’environnement de récupération Windows
Il ne s’agit donc pas d’une faille exploitable à distance via Internet.
Cependant, cela reste problématique pour :
les ordinateurs portables volés
les machines d’entreprise
les serveurs physiquement accessibles
les postes sensibles utilisant uniquement TPM sans PIN BitLocker
Le chercheur Kevin Beaumont a confirmé avoir reproduit le problème sur certains systèmes.
BitLocker et WinRE au cœur du problème
La faille exploiterait le fait que certains composants WinRE conservent un accès au volume déchiffré pendant certaines phases de récupération système ou de démarrage.
Le PoC utiliserait notamment :
des transactions NTFS
des fichiers spéciaux placés dans System Volume Information
des mécanismes internes liés à WinRE
Cela permettrait de contourner certaines protections BitLocker sur des configurations TPM-only.
Les configurations utilisant TPM + PIN pourraient être mieux protégées, même si le chercheur affirme disposer d’autres variantes non publiées.
Microsoft n’a pas encore publié de correctif
À l’heure actuelle, Microsoft n’a pas encore publié de correctif officiel ni attribué de CVE publique à YellowKey.
Le contexte est également particulier car le chercheur « Chaotic Eclipse » avait déjà publié récemment plusieurs zero-days Windows après avoir accusé Microsoft d’avoir ignoré certains rapports de sécurité.
Parmi les précédentes vulnérabilités publiées :
BlueHammer
RedSun
UnDefend
GreenPlasma
Microsoft avait finalement corrigé discrètement certaines d’entre elles après publication publique des PoC.
BitLocker a déjà connu plusieurs problèmes récents
Cette nouvelle vulnérabilité intervient alors que BitLocker a déjà rencontré plusieurs incidents ces derniers mois.
Récemment, certaines mises à jour Windows 11 comme KB5083769 et KB5082052 provoquaient des demandes inattendues de récupération BitLocker sur certains PC après modification des fichiers de démarrage et des paramètres TPM/PCR7.
Après plusieurs incidents liés aux pilotes distribués par Windows Update, Microsoft annonce une nouvelle fonctionnalité baptisée Cloud-Initiated Driver Recovery (CIDR). L’objectif est simple : permettre à Windows 11 de revenir automatiquement à un pilote stable lorsqu’une mise à jour provoque des plantages ou des dysfonctionnements matériels.
Cette annonce intervient alors que Microsoft reconnaît également un autre problème : Windows 11 remplace parfois des pilotes graphiques récents par des versions plus anciennes via Windows Update.
Microsoft veut éviter les catastrophes de pilotes via Windows Update
Les pilotes restent l’une des principales causes de crashs, BSOD et problèmes matériels sous Windows. Lorsqu’un pilote défectueux est publié via Windows Update, les conséquences peuvent être importantes :
Jusqu’à présent, la correction dépendait souvent :
d’un nouveau pilote publié par le constructeur
d’une désinstallation manuelle
d’un rollback local effectué par l’utilisateur
Avec Cloud-Initiated Driver Recovery, Microsoft pourra désormais déclencher à distance un retour automatique vers un pilote stable directement via Windows Update.
Le système fonctionne côté cloud depuis l’infrastructure Windows Update.
Lorsqu’un pilote est détecté comme problématique pendant les validations qualité ou après des signalements massifs :
Microsoft identifie le pilote défectueux
crée une demande de récupération
pousse automatiquement un rollback vers les PC concernés
Windows remplacera alors le pilote problématique par :
une ancienne version stable
ou un pilote approuvé compatible
Le tout sans intervention utilisateur ni action du constructeur OEM.
Microsoft précise également que cette récupération utilisera l’infrastructure Windows Update existante. Aucun nouvel agent ou logiciel supplémentaire ne sera nécessaire.
Une réponse aux nombreux problèmes de pilotes récents
Cette évolution n’arrive pas par hasard.
Depuis plusieurs années, Microsoft multiplie les problèmes liés aux pilotes distribués automatiquement :
pilotes Intel instables
conflits Wi-Fi/Bluetooth
BSOD après Patch Tuesday
pilotes GPU remplacés
incompatibilités OEM
Plus récemment, Microsoft a reconnu que Windows 11 pouvait remplacer des pilotes graphiques installés manuellement par des versions plus anciennes provenant de Windows Update.
Windows 11 downgrade parfois les pilotes graphiques
Le problème concerne surtout les pilotes GPU :
NVIDIA
AMD
Intel Arc
Des utilisateurs installent un pilote récent depuis le site du fabricant, mais Windows Update peut ensuite réinstaller automatiquement une version OEM plus ancienne.
Cela provoque parfois :
perte de performances
disparition de fonctionnalités
incompatibilités
bugs graphiques
régressions de jeux
Le phénomène existe depuis longtemps, mais Microsoft admet désormais officiellement le problème.
Cependant, Windows Update détecte ensuite qu’un autre pilote provenant de son catalogue OEM — ici la version 32.0.101.7085 — est considéré comme « mieux adapté » au matériel selon son système de ciblage matériel CHID.
Windows remplace alors automatiquement le pilote installé manuellement par cette autre version lors d’une mise à jour de pilotes.
L’utilisateur pense donc que son pilote n’a pas été correctement mis à jour et réinstalle à nouveau la version proposée par DriversCloud. Quelques jours plus tard, Windows Update effectue une nouvelle rétrogradation, créant ainsi une boucle de mises à jour entre deux versions différentes du pilote graphique.
Ce comportement illustre précisément le problème reconnu récemment par Microsoft concernant les downgrades automatiques de pilotes graphiques via Windows Update.
Microsoft prépare une correction pour le ciblage des pilotes
Microsoft explique que le problème vient notamment du système de ciblage matériel des pilotes Windows Update (CHID).
Le système actuel peut considérer qu’un pilote OEM plus ancien est “mieux adapté” qu’une version plus récente installée manuellement.
Pour corriger cela, Microsoft prépare un nouveau modèle de ciblage plus précis afin d’éviter les downgrades involontaires. Un pilote récent installé manuellement devrait donc être moins facilement remplacé à l’avenir.
Le déploiement progressif des nouvelles règles est prévu entre 2026 et 2027.
Windows Update devient de plus en plus autonome
Avec Cloud-Initiated Driver Recovery, Microsoft poursuit l’évolution de Windows Update vers un système capable de gérer lui-même une partie des problèmes logiciels et matériels. L’objectif est de limiter les situations où un pilote défectueux peut rendre un PC instable pendant plusieurs jours en attendant une intervention manuelle.
Windows 11 intègre déjà de nombreux mécanismes automatiques de réparation, de rollback et de vérification de compatibilité. Désormais, Microsoft veut également pouvoir réagir rapidement côté cloud lorsqu’un pilote problématique est détecté à grande échelle.
Cette approche s’inscrit dans une évolution plus large de Windows Update, qui devient progressivement une plateforme centralisée de maintenance capable de corriger certains problèmes sans action de l’utilisateur ou du constructeur.
Les utilisateurs de Windows 11 sont de plus en plus nombreux à remarquer deux phénomènes : des mises à jour qui nécessitent plusieurs redémarrages et des téléchargements toujours plus volumineux. Certaines mises à jour mensuelles dépassent désormais les 4 à 5 Go dans le catalogue Microsoft.
Microsoft a récemment donné plusieurs explications sur ces changements. Entre l’évolution du modèle cumulatif de Windows Update, les certificats Secure Boot 2023 et l’intégration de nouvelles fonctionnalités IA, le système de mise à jour de Windows devient nettement plus complexe qu’il y a quelques années.
Pourquoi certaines mises à jour Windows nécessitent plusieurs redémarrages
Traditionnellement, une mise à jour mensuelle de Windows nécessitait un seul redémarrage. Mais depuis les mises à jour d’avril et mai 2026, certains utilisateurs observent deux voire trois redémarrages successifs pendant l’installation.
Microsoft confirme que ce comportement est normal et qu’il est principalement lié au déploiement des nouveaux certificats Secure Boot 2023. Ces derniers remplacent progressivement les anciens certificats de 2011 qui expirent en juin 2026.
Le problème est que la mise à jour des certificats Secure Boot touche directement la chaîne de démarrage UEFI. Windows doit donc appliquer plusieurs opérations sensibles :
Réinitialisation de certaines données de démarrage
Finalisation de la configuration après reboot
Chaque étape peut nécessiter un redémarrage séparé afin d’éviter un échec du démarrage sécurisé.
Microsoft précise aussi que seuls certains PC sont concernés, notamment ceux n’ayant pas encore reçu les nouveaux certificats ou disposant d’un firmware UEFI nécessitant une procédure particulière.
Microsoft veut réduire les redémarrages à l’avenir
En parallèle, Microsoft travaille justement à réduire le nombre de redémarrages liés à Windows Update.
La firme teste actuellement un nouveau système qui regroupe davantage les mises à jour :
pilotes
.NET
composants système
firmware
L’objectif est de coordonner les installations afin qu’un seul redémarrage applique plusieurs mises à jour en même temps.
Windows 11 devrait aussi devenir plus transparent sur ce qui est réellement installé, avec des informations plus détaillées dans Windows Update.
Des mises à jour plus volumineuses dans Windows 11 25H2 et 24H2
Voici un graphique qui montre l’évolution de la taille des mises à jour cumulatives mensuelle de Windows 11 22H2 à Windows 25H2
Ce graphique donne la taille moyenne des mises à jour de Windows 11 par version.
Les graphiques mettent clairement en évidence une rupture à partir de Windows 11 24H2. Alors que les mises à jour cumulatives de Windows 11 22H2 et 23H2 restent relativement stables autour de 800 Mo à 1 Go, celles de Windows 11 24H2 et 25H2 dépassent régulièrement les 4,5 à 5 Go.
L’écart est particulièrement visible sur le graphique des moyennes : Windows 11 24H2 et 25H2 affichent une taille moyenne d’environ 4,8 Go, soit près de cinq fois plus que Windows 11 23H2. Cette hausse n’est donc pas ponctuelle mais structurelle, ce qui confirme un changement profond dans la manière dont Microsoft construit et distribue ses mises à jour cumulatives.
Les courbes montrent également que Windows 11 24H2 et 25H2 évoluent presque en parallèle avec des tailles très proches d’un mois à l’autre. Cela suggère que les deux versions reposent sur le même socle système et le même modèle de maintenance, contrairement aux anciennes versions de Windows 11 qui utilisaient des packages nettement plus légers.
Pourquoi les mises à jour Windows deviennent gigantesques
L’autre changement visible concerne la taille des mises à jour cumulatives.
Selon une analyse de Windows Latest, certains fichiers .msu dépassent désormais 5 Go, contre quelques centaines de Mo il y a encore deux ans. Une fois décompressées, certaines mises à jour approchent même les 9 Go.
L’intelligence artificielle est souvent accusée d’être responsable de cette inflation, mais la réalité est plus complexe.
L’IA augmente bien la taille des mises à jour
Windows 11 intègre désormais de nombreux composants liés à l’IA :
Copilot
modèles IA locaux
recherche sémantique
traitement NPU
composants de langage
Ces modules ajoutent plusieurs gigaoctets de fichiers supplémentaires dans les packages système.
Même si tous les PC ne les utilisent pas activement, Microsoft les inclut souvent dans les packages cumulés afin de simplifier le déploiement global.
Le vrai problème vient surtout du modèle cumulatif
Mais le principal responsable reste le fonctionnement même des mises à jour cumulatives de Windows.
Depuis plusieurs années, Microsoft utilise un modèle où chaque mise à jour contient l’ensemble des correctifs précédents. Cela simplifie énormément les nouvelles installations :
un seul package suffit
pas besoin d’installer des dizaines de correctifs séparés
restauration plus simple
meilleure cohérence système
En revanche, ce modèle entraîne une croissance constante des packages. Même un petit correctif de sécurité peut être intégré dans un énorme ensemble contenant des milliers de fichiers et composants destinés à toutes les configurations matérielles possibles.
Microsoft utilise bien des technologies comme Express Updates et UUP pour réduire les téléchargements réellement reçus par chaque PC, mais les packages du catalogue Microsoft restent massifs.
Un socle système beaucoup plus important
Windows 11 24H2 introduit un socle système plus moderne et plus complet. Microsoft intègre désormais davantage de composants directement dans les mises à jour cumulatives :
composants de sécurité
bibliothèques système
modules WinUI et WebView2
composants IA et Copilot
pilotes intégrés (inbox drivers)
composants ARM64/x64 partagés
Résultat : les mises à jour contiennent beaucoup plus de fichiers et de composants qu’auparavant.
Une nouvelle approche des mises à jour cumulatives
Microsoft privilégie désormais davantage la fiabilité et la capacité de réparation du système plutôt que des mises à jour ultra-compactes.
Concrètement, Windows Update embarque davantage de composants complets afin de :
uniformiser les versions entre éditions et architectures
Cette approche augmente la taille des packages téléchargés, mais améliore généralement la stabilité du système.
Windows 11 25H2 repose sur le même socle
Les tailles très proches entre Windows 11 24H2 et 25H2 montrent également que Windows 11 25H2 repose probablement sur le même socle technique que 24H2.
Microsoft utilise de plus en plus un modèle proche des “enablement packages”, où une nouvelle version de Windows active simplement des fonctionnalités déjà présentes dans le système, sans reconstruire entièrement une nouvelle branche Windows.
Pourquoi la taille affichée des mises à jour peut être trompeuse
Autre élément important : la taille d’une mise à jour Windows peut varier énormément selon l’endroit où elle est affichée.
Microsoft utilise aujourd’hui plusieurs mécanismes de compression, de téléchargement différentiel et de déduplication. Résultat : un package peut faire plusieurs gigaoctets dans le catalogue Microsoft alors que le PC ne télécharge réellement qu’une petite partie des fichiers.
C’est notamment lié aux technologies UUP (Unified Update Platform) et Express Updates qui évitent de retélécharger les composants déjà présents sur le système.
Voici les principales différences :
Type de taille
Description
Taille du package .msu
Taille complète du fichier disponible dans le Microsoft Update Catalog
Taille du téléchargement réel
Quantité réellement téléchargée par Windows Update sur le PC
Taille décompressée
Taille une fois les fichiers extraits et préparés pour l’installation
Taille installée
Espace réellement occupé dans le système après installation
Connexion
Korben
Windows Central - News, Forums, Reviews, Help for Windows 10 and all things Microsoft.
malekal.com
