CVE-2026-68896 : élévation de privilèges locale dans le composant Windows Search

Pourquoi nous avons suivi un catalogue utilisateur

Après le travail sur CBS, nous avons cherché le même type d’écart d’identité dans un autre service Windows : du code qui traite prudemment les fichiers d’un utilisateur à un endroit, mais oublie son identité ailleurs. Sur les hôtes multisessions, Windows Search entretient un catalogue distinct par utilisateur. Son cycle de vie à la connexion était donc plus intéressant que l’indexation ordinaire : un nettoyage exécuté par SearchIndexer.exe pouvait atteindre un chemin situé dans le profil modifiable d’un compte peu privilégié.

Nous avons comparé deux routes dans mssrch.dll. Celle de l’exploration et du contrôle d’accès empruntait l’identité de l’utilisateur. Le nettoyage du catalogue, appelé à la connexion, gardait l’identité SYSTEM du service pendant la suppression récursive. L’écart dans le code était prometteur, mais notre première question était : ce chemin est-il actif sur un hôte réel ? La valeur EnablePerUserCatalog ressemblait à un interrupteur facultatif. L’analyse statique a montré qu’en son absence, le code retombait sur un contrôle de la suite Windows et activait par défaut les catalogues par utilisateur sur les systèmes configurés en multisession. Nous avons vérifié cette porte sur des hôtes RDS, sans déduire le comportement d’une simple capture du registre.

Cette vérification nous a d’abord trompés. Une reproduction PowerShell de VerifyVersionInfoW annonçait un mauvais état de la suite à cause du comportement de version de son hôte. Une sonde native, plus proche de la façon dont mssrch.dll interroge les bits de suite, montrait le bit Terminal Server présent et le bit mono-utilisateur absent. Sans ce contrôle, nous aurions pu conclure à tort que la voie était désactivée par défaut.

Prouver la suppression avant de chercher l’exécution SYSTEM

Le chemin venait du profil de l’utilisateur, et ce même utilisateur pouvait redéclencher le nettoyage par une connexion interactive. Nous avons préparé une redirection du catalogue et la valeur pertinente dans sa propre ruche. Avant la connexion, nous avons placé un fichier témoin dans un répertoire dont l’ACL autorisait SYSTEM et les administrateurs, mais pas ce compte standard. Une tentative de suppression par ce compte a renvoyé Access denied. Lors de sa connexion suivante, le nettoyage SYSTEM de Search a supprimé le fichier. Le répertoire qui le contenait a survécu. Cette nuance définissait notre primitive : une suppression de contenu sous un répertoire redirigé, pas, dans ce premier essai, une suppression arbitraire du répertoire racine.

La connexion elle-même demandait un contrôle précis. Une session RDP simplement déconnectée gardait ouverte la base du catalogue ; le chemin n’était pas libre pour être remplacé. Il fallait fermer complètement la session, puis rouvrir une session interactive, afin de libérer les handles et relancer le cycle de vie. Un échec avec une session seulement déconnectée aurait été un problème d’état du laboratoire, pas une preuve de protection du code.

Une suppression par SYSTEM peut parfois être convertie en exécution via d’autres mécanismes Windows. Nous avons développé et exercé cette suite, mais elle était plus conditionnelle que le défaut de suppression. Sur une image Server minimale, l’état Windows Installer nécessaire n’était pas accessible au programme non administrateur comme sur un client doté d’un inventaire MSI plus riche. Lors du rejeu sur installation fraîche du 7 juin, la préparation et la connexion déclenchant la suppression protégée étaient non administratrices, tandis que l’automatisation de la suite était lancée avec élévation pour piloter le labo sans interface. La preuve finale contenait un jeton SYSTEM, mais cet essai seul ne doit pas être présenté comme une chaîne d’exécution entièrement pilotée sans privilège. Les essais antérieurs ont exercé cette conversion dans d’autres états ; le résultat sans cette réserve est la suppression protégée depuis le compte standard.

Pourquoi nous avons réinstallé le laboratoire

Nous ne voulions pas qu’une ancienne image, un catalogue résiduel ou une option de registre explique le résultat. Le 7 juin, nous avons réinstallé Server 2025 en hôte RDS, recompilé le PoC depuis les sources, confirmé que la protection temps réel de Defender était active et que EnablePerUserCatalog n’était pas forcé. Le compte peu privilégié ne pouvait toujours pas supprimer directement le fichier témoin ; Search l’a effacé lors de la connexion suivante de ce compte. Nous avons conservé séparément la valeur native de la porte et l’état du fichier avant/après. Ce rejeu propre renforce la découverte centrale ; il n’efface pas la réserve sur sa conversion.

Nous avons transmis à Microsoft le chemin de code, la preuve non administratrice et les conditions de la suite vers l’exécution. Après la publication de CVE-2026-68896 le 8 septembre, nous avons rejoué la voie initiale sur Windows 11 25H2 corrigé, build 26200.9445 : une entrée a renvoyé 0x80070005, et un autre déclencheur du catalogue a atteint son consommateur sans supprimer la cible protégée. Nous gardons ces deux observations, car le refus d’un appel ne dit pas, à lui seul, ce que ferait un nettoyage effectivement atteint.

La portée publiée

L’avis Microsoft qualifie le défaut de traversée de chemin absolu (CWE-36), lui attribue 7,8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) et crédite notre chercheur pour ce travail. À la publication, Microsoft jugeait l’exploitation peu probable et ne signalait pas d’exploitation observée. Les détails sur le catalogue et nos essais viennent du dossier de recherche, pas du court bulletin de l’éditeur. Dans nos tests, un poste mono-utilisateur n’activait pas ce mode par défaut ; la porte multisession est indispensable pour comprendre la découverte.

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 2022	20348.5622	KB5122882
Windows Server 2025	26100.33438	KB5122871

Installez la mise à jour de septembre 2026 applicable, ou une cumulative ultérieure, surtout sur les hôtes RDS et ceux où des utilisateurs de confiance différente partagent la machine. Le point de départ est un compte local peu privilégié, pas un service Search attaquable à distance. Nous ne publions pas toute la chaîne ; une alerte générique sur les opérations fichier de Search ne serait pas une signature fiable. Conservez les traces des processus et fichiers autour d’une élévation suspecte.

Chronologie

Date	Ce que nous avons établi
Fin mai 2026	Comparaison entre accès au catalogue sous identité utilisateur et nettoyage SYSTEM ; vérification de la porte multisession
7 juin 2026	Labo réinstallé : la connexion non administratrice supprime un fichier protégé ; son répertoire survit
Juin 2026	Conditions de la conversion suppression→exécution documentées et dossier envoyé au MSRC
8 septembre 2026	Publication de CVE-2026-68896 et du correctif
9 septembre 2026	Voie d’origine et contrôle négatif du catalogue testés sur 26200.9445