CVE-2026-0386 : Microsoft va bloquer le déploiement automatique de Windows en avril — ce que tu dois faire maintenant

Microsoft désactive le déploiement hands-free WDS en avril 2026 suite à une faille RCE critique (CVE-2026-0386). Si tu utilises Windows Deployment Services avec Unattend.xml, tu as jusqu’en avril pour agir — ou tes déploiements s’arrêteront.

CVE-2026-0386 : Microsoft va bloquer le déploiement automatique de Windows en avril — ce que tu dois faire maintenant

Si tu utilises Windows Deployment Services (WDS) pour déployer Windows en masse dans ton parc, tu as jusqu'en avril 2026 pour agir. Après ça, Microsoft désactivera automatiquement le déploiement hands-free — et si tu n'as rien préparé, tes déploiements automatisés s'arrêteront net.

Voici exactement ce qui se passe, pourquoi, et ce que tu dois faire maintenant.

C'est quoi WDS et le déploiement hands-free ?

Windows Deployment Services (WDS) est un rôle serveur Windows qui permet de déployer des systèmes d'exploitation à distance, via le réseau, en utilisant le protocole PXE (Preboot Execution Environment). En clair : tu branches un PC sur le réseau, il démarre en PXE, et Windows s'installe tout seul depuis le serveur WDS.

Le déploiement hands-free va un cran plus loin : il utilise un fichier Unattend.xml (aussi appelé fichier de réponses) pour automatiser toutes les étapes de l'installation — y compris la saisie des identifiants. Résultat : aucune intervention humaine n'est nécessaire pendant le déploiement. C'est la solution classique dans les grandes entreprises pour provisionner des centaines de postes rapidement.

Le problème : ce fichier Unattend.xml contient souvent des identifiants en clair. Et Microsoft vient de confirmer qu'il était transmis sur un canal non authentifié.

La faille CVE-2026-0386 : ce qui se passe vraiment

La vulnérabilité CVE-2026-0386, publiée le 13 janvier 2026, est classée CWE-284 (Improper Access Control). Le fichier Unattend.xml est transmis via un canal RPC non authentifié et est exposé via le partage RemoteInstall sans aucune vérification d'identité.

Concrètement, un attaquant positionné sur le même segment réseau — pas besoin d'être authentifié sur le domaine — peut :

  • Intercepter le fichier Unattend.xml en transit
  • Voler les identifiants qu'il contient (comptes de jonction de domaine, comptes admin locaux, etc.)
  • Injecter du code malveillant exécuté lors du déploiement
  • Obtenir des privilèges SYSTEM sur les machines en cours d'installation

Le scénario le plus dangereux : un attaquant qui empoisonne les images de déploiement. Chaque nouveau poste installé hérite du malware. C'est un risque de type supply chain à l'intérieur même de ton datacenter.

La faille affecte toutes les versions de Windows Server de 2008 à 2025, y compris Server 2016, 2019, 2022 et 23H2.

Point important : Microsoft Configuration Manager (SCCM) n'est pas affecté. SCCM utilise WDS uniquement pour servir les fichiers de boot réseau, pas le mécanisme Unattend.xml vulnérable.

Le planning Microsoft : deux phases, une deadline en avril

Microsoft déploie la correction en deux phases :

Phase 1 — 13 janvier 2026 (déjà appliquée)
Le déploiement hands-free reste fonctionnel mais peut être désactivé manuellement. Microsoft a introduit des alertes dans l'Observateur d'événements et une clé de registre pour permettre aux admins d'agir immédiatement.

Phase 2 — Avril 2026 (à venir)
Via une mise à jour de sécurité, Microsoft désactivera le hands-free deployment par défaut sur tous les serveurs WDS. Si tu n'as rien fait avant, tes déploiements automatisés s'arrêteront sans préavis.

Ce que tu dois faire maintenant

Deux options s'offrent à toi :

Option 1 : Désactiver manuellement le hands-free deployment (recommandé immédiatement)

Applique la clé de registre suivante sur ton serveur WDS pour désactiver le déploiement hands-free via canal non authentifié :

reg add "HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend" /v AllowHandsFreeFunctionality /t REG_DWORD /d 0 /f

Ensuite, redémarre le service WDS :

net stop WDSServer
net start WDSServer

Une fois cette clé appliquée, WDS demandera une confirmation manuelle lors des déploiements — le hands-free ne fonctionnera plus, mais ton infrastructure sera sécurisée.

Option 2 : Vérifier les alertes dans l'Observateur d'événements

Microsoft a ajouté des événements de log pour te prévenir si le hands-free deployment est encore actif et utilisé sur ton serveur. Dans l'Observateur d'événements, ouvre :

Applications and Services Logs → Microsoft → Windows → Deployment-Services-Diagnostics

Surveille les avertissements liés à l'accès non sécurisé au fichier Unattend.xml. Si tu en vois, ton serveur est exposé.

Les alternatives pour continuer à déployer Windows sans risque

Si tes process actuels reposent entièrement sur WDS avec Unattend.xml, il est temps de migrer. Les alternatives recommandées par Microsoft :

  • Microsoft Intune — gestion cloud, déploiement via Autopilot, pas de WDS nécessaire
  • Windows Autopilot — provisioning moderne, s'appuie sur Azure AD, aucun serveur de déploiement local requis
  • Microsoft Configuration Manager (SCCM) — la solution entreprise classique, non affectée par cette vulnérabilité

Si tu es sur une petite infrastructure avec WDS en standalone, la migration vers Intune/Autopilot est le chemin le plus propre à long terme. Si tu es sur SCCM, tu n'as rien à faire côté déploiement — mais assure-toi quand même d'appliquer le KB5074952 sur tes serveurs WDS.

Sources officielles