CVE-2026-81963 : élévation de privilèges locale dans le Windows Update Stack par suivi de lien

La piste qu’il a fallu retirer

Cette recherche est partie d’une question sur la portée d’un ancien correctif, pas d’un numéro de CVE. CVE-2020-0728 avait fermé un point d’entrée privilégié du servicing Windows. Nous voulions savoir si ce contrôle protégeait aussi les autres chemins de wcp.dll, qui manipule les fichiers de paquets pour TrustedInstaller. Un balayage a repéré de nombreuses opérations de fichier susceptibles de suivre un point de jonction. Ce n’étaient que des candidats : il fallait encore prouver qu’un utilisateur standard pouvait choisir le chemin, atteindre l’opération et provoquer une écriture protégée.

Notre première piste passait par une session CBS exposée en COM. Nous avons retrouvé les signatures des méthodes dans les binaires et les symboles, puis essayé Initialize, AddSource et Finalize. Le 1er mai, nos notes qualifiaient même le résultat de « breakthrough » : les appels avançaient assez loin dans CBS pour paraître prometteurs. Puis nous avons vérifié les traces du système de fichiers. Les accès TrustedInstaller annoncés n’étaient pas établis ; une nouvelle capture n’en trouvait aucun sur le chemin que nous contrôlions. Nous avons retiré la conclusion. Un appel COM réussi et une erreur de format de paquet ne prouvaient pas une écriture privilégiée.

Le contexte de test ajoutait un piège. L’activation COM de CBS acceptait une session standard interactive, alors que notre connexion SSH possédait un jeton réseau. Un ACCESS_DENIED depuis SSH ne permettait pas de trancher pour l’utilisateur qui nous intéressait. Nous avons donc vérifié la portée depuis une session interactive et gardé l’échec SSH comme une limite du montage, pas comme une protection du produit.

Deux extractions, deux identités

Nous avons reformulé la recherche : au lieu de demander « quelle méthode publique atteint une opération de fichier ? », nous avons cherché où CBS traite deux fois le même paquet sous deux identités différentes. Dans le chemin OnePackage, CreatePackage extrait le CAB en empruntant l’identité de l’appelant. Plus tard, EvaluateApplicability appelle ExternalEvaluateApplicability, qui réextrait le contenu sans reprendre cette identité. La session conserve son répertoire de travail entre les appels. Nous pouvions agir sur ce chemin, et le code d’ouverture suivait sa redirection lors de la seconde utilisation. Ce n’était pas une course à gagner au bon instant : le changement se faisait entre deux appels que nous déclenchions nous-mêmes.

Nous avons commencé par une preuve limitée. Sur Windows 11 23H2 build 22631.6937, nous sommes partis d’un compte non administrateur, avons constaté qu’il ne pouvait pas écrire dans la destination protégée, puis laissé CBS traiter un paquet de test. La seconde extraction redirigée y a créé un fichier sous TrustedInstaller. Nous avons répété cette écriture trois fois. EvaluateApplicability pouvait renvoyer une erreur après l’écriture ; s’en tenir au code de retour aurait masqué la vulnérabilité. Nous avons contrôlé le fichier et son propriétaire.

Une écriture privilégiée ne suffit pas à annoncer une élévation complète. Nous avons construit et testé séparément le passage de cette écriture à l’exécution de code, puis vérifié le jeton SYSTEM obtenu. La chaîne complète a réussi trois fois sur 23H2 et trois fois sur Windows 11 25H2 build 26200.8246. Ces chiffres concernent nos builds testés, pas toutes les configurations Windows. Nous ne publions ici ni l’exécutable ni l’emplacement exact de la chaîne d’exécution ; l’élément à retenir est la frontière vérifiée à chaque étape.

Le contrôle qui a changé notre lecture de l’impact

Le 4 mai 2026, nous avons transmis à Microsoft la cause racine, la preuve du passage du compte standard à SYSTEM et les éléments liés aux builds. Le soir même, nous avons ajouté une démonstration SYSTEM interactive ; le MSRC a ouvert la case 115491 le lendemain. Pendant l’échange, nous avons mieux séparé les deux impacts. Le 15 mai, sur un instantané Canary frais, nous avons tenté d’écrire directement dans un emplacement du magasin de composants en tant que SYSTEM : Access is denied. Après restauration, un programme de test réduit n’a exercé que le chemin d’écriture CBS. Il a déposé un marqueur au même endroit, sans déclencher la suite vers SYSTEM. Nous avons restauré de nouveau et vérifié l’absence du marqueur et du payload. Ce contrôle montre pourquoi réduire le défaut à « obtenir SYSTEM » oubliait la frontière d’écriture TrustedInstaller. Il ne démontre pas, à lui seul, tous les scénarios proposés de modification de politiques.

Microsoft a publié CVE-2026-81963 et son correctif le 8 septembre. Le 9, nous avons rejoué la voie initiale depuis un compte standard sur Windows 11 25H2 corrigé, build 26200.9445. Elle s’est arrêtée avec 0x80070005 avant la seconde extraction privilégiée. Nous avons aussi étudié une écriture voisine encore observable sur ce build : elle atteignait seulement un emplacement contrôlé par l’attaquant, sans opération trouvée pour la conduire à une cible protégée. Nous n’en avons pas fait un contournement. Notre examen de Server 2025 est statique ; nous n’avons pas rejoué ce chemin sur une VM Server.

Ce que l’avis public apporte

L’avis Microsoft classe le défaut comme suivi de lien et contrôle d’accès incorrect (CWE-59, CWE-284), lui attribue 7,8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) et signale une exploitation détectée. La CISA l’a ajouté au catalogue KEV le 8 septembre 2026. Microsoft crédite notre chercheur aux côtés de chercheurs du Microsoft Threat Intelligence Center. Aucun de ces avis ne dit que les attaques observées par Microsoft ont suivi notre séquence, ni n’identifie un acteur. Le récit ci-dessus vient de notre enquête et de la case MSRC, pas d’une déduction sur ces attaques.

Builds concernés et action

Produit	Premier build corrigé	Mise à jour
Windows 11 23H2	22631.7582	KB5122880
Windows 11 24H2 / 25H2	26100.9445 / 26200.9445	KB5124008
Windows 11 26H1	28000.2954	KB5124012
Windows Server 2025	26100.33438	KB5122871

Installez la mise à jour de septembre 2026 applicable, ou une cumulative ultérieure. Donnez la priorité aux hôtes partagés où du code peut déjà tourner avec de faibles privilèges. Comparez le build installé à la bonne ligne. Server 2022 ne figure pas dans la liste des produits touchés de Microsoft pour cette CVE, et nous n’y avons pas reproduit notre chaîne Windows 11 d’origine.

Une règle signalant toute jonction près d’un répertoire de servicing serait bruyante. Nous ne publions pas le chemin de l’exploit, donc nous ne pouvons pas proposer une signature de chemin fiable. Pour enquêter sur une tentative suspecte, conservez la télémétrie servicing, processus et fichiers, puis corrélez-la avec une transition locale de privilèges inhabituelle.

Chronologie

Date	Ce que nous avons établi
1er mai 2026	Retrait du premier « breakthrough » AddSource/Finalize après contrôle de la preuve fichier manquante
2 mai 2026	Écriture protégée depuis un compte standard, puis chaîne d’exécution SYSTEM sur 23H2
4–5 mai 2026	Signalement MSRC, mise à jour de la démonstration et ouverture de la case 115491
15 mai 2026	Comparaison entre un refus d’écriture directe SYSTEM et une écriture TrustedInstaller isolée dans une VM restaurée
8 septembre 2026	Publication du correctif, exploitation signalée par Microsoft et ajout au KEV
9 septembre 2026	Voie initiale arrêtée sur 26200.9445 ; écriture voisine sans accès à une cible protégée