À l’occasion du Patch Tuesday de janvier 2026, Microsoft a dévoilé une faille de sécurité présente dans WDS, les services de déploiement de Windows Server. Le correctif pour cette vulnérabilité associée à la référence CVE-2026-0386 pourrait perturber les utilisateurs de WDS. Voici ce que vous devez savoir.
Sur Windows Server, le rôle WDS (Windows Deployment Services) est souvent installé pour assumer la fonction de serveur PXE. Néanmoins, WDS est capable de gérer des images de démarrage (uniquement pour le boot) et des images d’installation de Windows.
C’est justement au niveau des images d’installation qu’un administrateur peut spécifier un fichier de réponse pour automatiser et personnaliser l’installation du système d’exploitation (ou réduire les interactions). Cela évite d’y associer MDT pour des personnalisations légères, et de toute façon, ce dernier est en fin de vie puisque Microsoft a supprimé la page de téléchargement de MDT.
Cet article me donne l’occasion de rappeler que WDS est partiellement déprécié : les systèmes récents comme Windows Server 2025 et Windows 11 ne le supportent pas bien (notamment en tant qu’images de démarrage).
L’impact de la CVE-2026-0386
Microsoft considère la CVE-2026-0386 comme une faille de sécurité importante dans WDS pouvant mener à une exécution de code à distance depuis le réseau local. Bien que l’attaque soit considérée comme complexe, aucun privilège n’est requis pour exploiter cette faiblesse. L’attaquant doit se situer sur le réseau local, afin de pouvoir agir en tant que man-in-the-middle.
“L’ancien workflow WDS transmet le fichier unattend.xml via un RPC non authentifié, exposant ainsi des informations d’identification sensibles lors du démarrage PXE. Cela crée un risque pour la sécurité, notamment des attaques de type « man-in-the-middle » (MITM). Afin de renforcer la sécurité, Microsoft impose par défaut l’authentification RPC et supprime le workflow non sécurisé.”, peut-on lire dans le bulletin de sécurité.
Pour corriger cette vulnérabilité, Microsoft s’attaque donc aux fichiers de réponse unattend.xml et aux déploiements hands-free, c’est-à-dire sans intervention manuelle. Ce fichier de réponse peut contenir des informations sensibles et permettre l’exécution de commandes, ce qui ouvre la voie à diverses actions malveillantes si la transmission est effectuée de façon non sécurisée.
Cette vulnérabilité affecte les versions de Windows Server 2008 à Windows Server 2025, y compris les serveurs en mode Core.
La feuille de route de Microsoft
Si vous installez les mises à jour de janvier 2026, tout continuera de fonctionner normalement. Microsoft a prévu un déploiement du correctif en deux temps : une première phase le 13 janvier 2026 (nous y sommes) et une deuxième phase en avril 2026, soit dans 3 mois.
La mise à jour de janvier 2026 ajoute des capacités d’audit : si votre serveur WDS a une configuration problématique vis-à-vis de la CVE-2026-0386, cela va générer des logs dans l’Observateur d’événements (ici : Microsoft-Windows-Deployment-Services-Diagnostics/Debug).
De plus, cette mise à jour introduit un nouveau paramètre de Registre pour passer en mode sécurisé. Par défaut, rien ne change, c’est à vous de faire le choix de durcir la configuration.
La mise à jour prévue en avril 2026 (le 14 avril 2026 en principe) va modifier le nouveau paramètre de Registre pour forcer le mode sécurité par défaut. C’est donc à partir d’avril 2026 que le correctif de sécurité sera activé par défaut sur l’ensemble des machines concernées.
“Le déploiement hands-free ne fonctionnera plus, sauf s’il est explicitement remplacé par les paramètres du Registre.”, précise Microsoft sur son site. Donc, les administrateurs garderont tout de même la main pour agir sur cette fonctionnalité en jouant avec la clé de Registre.
À partir de cette date, les fichiers de réponse seront transmis via un canal sécurisé, par défaut.
Durcir la configuration de WDS
Si vous souhaitez passer à l’action dès maintenant et durcir la configuration de votre serveur WDS, vous devez créer une valeur dans le Registre. Que ce soit avec regedit, reg add ou PowerShell, voici la configuration cible :
Chemin : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WdsServer\ Providers\WdsImgSrv\Unattend
Nom de la valeur DWORD : AllowHandsFreeFunctionality
Valeur : 00000000
Directement via reg add :
reg add “HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend” /v AllowHandsFreeFunctionality /t REG_DWORD /d 0 /f
Note : pour que ce changement soit pris en compte par le serveur WDS, vous devrez probablement redémarrer le service.
Cela a pour effet de forcer l’accès authentifié au fichier unattend.xml et de désactiver le déploiement hands-free. Microsoft n’explique pas réellement quels sont les changements opérés sur ce mécanisme.
Si vous utilisez les fichiers de réponse avec WDS et que vous effectuez des tests avec cette valeur, n’hésitez pas à faire un retour via un commentaire.
Ingénieur système et réseau, cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.