Defender for Endpoint : valider la visibilité WSLc en disponibilité générale
Microsoft classe le support Defender for Endpoint des WSL containers en disponibilité générale dans ses nouveautés de septembre 2026, avec le plug-in 2.26.921.1. Les équipes qui utilisent WSLc sur des postes Windows doivent valider la santé de chaque instance et sa visibilité dans Defender, sans assimiler cette couverture à un antivirus Linux complet.
- Impact
- postes Windows compatibles, déjà intégrés à Defender for Endpoint Plan 2, exécutant des WSL containers ; ARM64 et Windows multisession sont exclus.
- Action
- sur un poste représentatif, contrôler les prérequis, installer le MSI documenté, puis comparer les instances actives aux résultats de HealthCheck et à l’inventaire Defender.
- Statut
- À tester
Ce qui change depuis la préversion
Le journal Defender comporte une entrée GA pour WSLc et nomme explicitement le plug-in 2.26.921.1. L’entrée historique Preview reste présente plus bas. Il s’agit d’une évolution rattachée à septembre 2026, sans jour de disponibilité précisé, et non d’une annonce du 21 octobre.
Cette actualisation remplace les consignes de préversion : la documentation actuelle indique un MSI téléchargeable dans Settings > Endpoints > Onboarding > Windows Subsystem for Linux 2 (plug-in). Le sujet reste utile maintenant pour éviter de préparer un déploiement à partir des anciens prérequis.
La GA citée concerne le support Defender pour WSLc. Elle ne démontre ni l’activation du plug-in sur votre parc, ni une couverture équivalente à celle d’un agent Linux autonome.
Un périmètre et des versions à distinguer
La documentation Defender exige WSL 2.9.12 ou ultérieur pour WSLc. Le tutoriel général WSLc mentionne 2.9.3 pour disposer de l’outil conteneur : ce seuil ne suffit donc pas pour valider l’intégration Defender.
La liste de validation Microsoft demande de contrôler les versions suivantes : plug-in 2.26.921.1, WSL 2.9.12 et application Defender 101.26081.0010, ou des versions supérieures conformément à cette liste. Ce sont des repères de compatibilité, pas des versions minimales corrigeant une CVE.
Les noyaux et lignes de commande de noyau personnalisés ne sont pas pris en charge. Le périphérique logique WSL expose des événements de sécurité, mais pas l’antimalware, la gestion des vulnérabilités ni les commandes de réponse.
Valider une instance réellement visible
Choisir un poste Windows 11 x64 représentatif des usages WSLc, avec la connectivité habituelle de l’entreprise. Avant installation, enregistrer les instances actives et prévenir l’utilisateur : Microsoft indique que l’installation arrête WslService s’il fonctionne. Après installation, relancer le workload nécessaire au contrôle.
Sur l’hôte Windows, lancer l’outil healthcheck.exe, situé dans %ProgramFiles%\Microsoft Defender for Endpoint plug-in for WSL\tools, après au moins cinq minutes d’initialisation. La procédure Microsoft demande que toutes les VM WSLc actives soient listées et que chacune indique Healthy. Ne pas se limiter à la présence du MSI dans l’inventaire logiciel.
Dans l’inventaire du portail Defender, utiliser le tag WSL2, puis ouvrir l’appareil et vérifier son lien vers l’hôte Windows. Comparer les événements de la chronologie à une activité connue du workload. Microsoft prévient qu’une instance peut demander jusqu’à 30 minutes pour apparaître ; les instances très brèves peuvent ne pas être visibles.
Poursuivre l’élargissement si les VM attendues sont saines, associées au bon hôte et alimentent la chronologie. Sinon, suspendre l’élargissement et examiner les droits de consultation, le temps d’activité et la connectivité. Un résultat de connectivité invalid dans HealthCheck appelle un diagnostic réseau/proxy, pas une conclusion de protection fonctionnelle.
Ces contrôles constituent une recommandation PatchFactory ; ils n’ont pas été exécutés sur un poste pour cet article.