CVE-2026-72982 Netlogon : exécution de code à distance, vérifier le correctif

Synthèse

L’exécution de code à distance Netlogon CVE-2026-72982 exige une vérification urgente de l’état des correctifs sur chaque contrôleur de domaine concerné. Le CVRF Microsoft de septembre 2026 décrit un dépassement de tampon sur la pile accessible par le réseau, sans authentification ni interaction de l’utilisateur. La priorité opérationnelle consiste à identifier le produit Windows exact de chaque serveur, à confirmer la mise à jour de sécurité applicable et à vérifier que son déploiement et le redémarrage requis sont terminés.

Vérifié le 3 octobre 2026 : Microsoft classe la vulnérabilité comme critique, avec un score de base CVSS 3.1 de 9.8. L’entrée a été publiée initialement le 8 septembre 2026 : il s’agit d’une vulnérabilité de septembre examinée en octobre, et non d’une nouvelle divulgation d’octobre. Les faits ci-dessous proviennent du JSON CVRF MSRC de septembre 2026.

La CVE est absente du catalogue CISA KEV lors de la vérification du 3 octobre 2026, dans le catalogue KEV téléchargé, version 2026.10.02. Cette observation et l’évaluation de l’exploitation par Microsoft sont deux instantanés distincts. Aucun ne prouve qu’une exploitation est impossible ni ne justifie de reporter la mise à jour.

CVE-2026-72982 Netlogon : exécution de code à distance

Microsoft décrit un attaquant envoyant un paquet réseau spécialement conçu à un service affecté et pouvant exécuter du code sur le système cible. La faiblesse est un dépassement de tampon sur la pile. La FAQ publiée écarte explicitement deux prérequis courants : l’attaquant n’a pas besoin de compte et l’utilisateur n’a rien à cliquer ni à approuver. Un accès réseau au service affecté reste nécessaire.

Pour les défenseurs, la question immédiate est donc de déterminer quels systèmes affectés restent accessibles et non corrigés. Le CVRF ne fournit ni signature de paquet, ni événement spécifique à l’exploitation, ni preuve d’une campagne active. Ne déduisez pas du seul score une charge utile particulière, une chaîne de processus, un niveau de privilège après exploitation ou une capacité de propagation autonome.

Cette vulnérabilité est distincte de l’application des protections Zerologon CVE-2020-1472. Cet article traite de l’ancienne faille du canal sécurisé Netlogon et de l’historique de l’application de ses protections. Ces paramètres et correctifs historiques ne permettent pas d’établir si le correctif du dépassement de tampon de septembre 2026 est installé.

Vérifier le bon correctif sur chaque contrôleur de domaine

Commencez par un inventaire complet des DC, y compris les installations Server Core et les contrôleurs de domaine en lecture seule. Consignez pour chaque machine le produit du système d’exploitation, le build installé, la KB applicable, le résultat du déploiement et la fin du redémarrage. Évitez de contrôler un seul DC visible puis d’extrapoler son résultat à toute la forêt.

La correspondance Windows Server suivante provient directement de la jointure des Remediations de cette CVE avec le ProductTree du CVRF. Elle couvre les produits serveur qui y figurent ; le document répertorie également des produits Windows clients. Consultez le CVRF complet pour la remédiation des clients.

Pour toutes les remédiations par mise à jour de sécurité ci-dessus, RestartRequired vaut Yes. Les entrées 2012 et 2012 R2 sont des entrées Monthly Rollup ; ne déduisez pas de ce tableau une éligibilité générale à leur installation. Vérifiez les modalités de maintenance applicables à votre environnement. Un numéro de version correspondant à un autre produit Windows n’est pas une preuve de couverture.

Pour un DC Windows Server 2025, la documentation Microsoft de Get-HotFix décrit le filtrage par -Id et l’interrogation d’un ordinateur distant avec -ComputerName. Adaptez le modèle documenté à la KB applicable :

Get-HotFix -Id KB5122871

Pour un DC Server 2025 distant, remplacez le nom d’exemple par celui de votre hôte réel :

Get-HotFix -Id KB5122871 -ComputerName DC01

Ces commandes ont été vérifiées dans la documentation, sans être exécutées sur un DC de production. Pour une autre version de serveur, substituez la KB du tableau. Un enregistrement retourné étaye l’installation de la mise à jour nommée ; il ne prouve pas que le redémarrage requis est terminé. Une erreur d’accès ou de connectivité est un résultat inconnu, pas un constat de correctif manquant.

Get-HotFix utilise Win32_QuickFixEngineering et présente des limites d’inventaire documentées. L’absence d’une ancienne KB ne suffit pas à conclure à une vulnérabilité : rapprochez le build installé et l’historique de maintenance, y compris toute mise à jour cumulative qui la remplace, dans vos données de gestion des correctifs. N’utilisez pas uniquement la date d’installation de la mise à jour la plus récente comme preuve de couverture de cette CVE.

Pour Server 2025, la page Microsoft KB5122871 confirme indépendamment le build du système d’exploitation 26100.33438. La même page indique que le problème RDS introduit par la mise à jour de septembre a été résolu dans les mises à jour publiées à partir du 14 septembre 2026, dont KB5129235, et recommande la dernière mise à jour applicable. Considérez le tableau comme la correspondance du correctif initial, puis évaluez la mise à jour cumulative actuellement applicable et les problèmes connus avant le déploiement.

Détection : signaux utiles et limites

La vérification de l’exposition offrant ici le plus haut niveau de confiance est la conformité des correctifs pour le produit exact du système d’exploitation. Déclenchez une alerte pour tout DC affecté dont le correctif applicable ou une mise à jour de remplacement vérifiée manque, dont le déploiement a échoué ou dont le redémarrage reste en attente. Placez les enregistrements d’inventaire inaccessibles ou obsolètes dans une file explicitement marquée comme inconnue jusqu’à leur vérification.

L’annexe L de Microsoft Learn : événements à surveiller documente deux événements Netlogon :

Ce sont des signaux de posture des canaux sécurisés, pas des indicateurs documentés d’exploitation de CVE-2026-72982. Leur présence ne démontre pas une RCE réussie ; leur absence ne démontre pas qu’un DC est corrigé. Examinez-les avec l’état des correctifs et votre télémétrie existante des terminaux et du réseau, plutôt que de créer une alerte attribuant chaque occurrence à cette CVE.

Microsoft recommande de tester les recommandations de surveillance des événements dans l’environnement local et de revoir la configuration de journalisation. Confirmez que la collecte fonctionne sur chaque DC avant d’interpréter un tableau de bord silencieux. L’avis primaire utilisé ici ne fournit aucune détection KQL propre à la CVE ; aucune signature d’exploitation vérifiée n’est disponible pour être reproduite.

Remédiation : corriger, redémarrer et résoudre les inconnues

1. Identifiez le produit avant de choisir la mise à jour. Utilisez le ProductID et la remédiation du CVRF pour cette version de serveur, puis examinez la mise à jour cumulative actuellement applicable et ses prérequis.
2. Déployez par votre canal de mise à jour habituel. Donnez la priorité aux DC accessibles et non corrigés et planifiez les travaux en tenant compte de la disponibilité de l’authentification. Conservez le résultat de la mise à jour pour chaque hôte.
3. Terminez le redémarrage requis. Un paquet téléchargé, un déploiement approuvé ou une ligne de correctif installé ne vaut pas une opération de maintenance terminée.
4. Vérifiez de nouveau le build en cours d’exécution et les preuves de mise à jour. Rapprochez la correspondance KB/build, les éventuels remplacements et les enregistrements de déploiement. Validez l’authentification et la réplication avant de clore le changement.
5. Si une correction immédiate est bloquée, réduisez l’accessibilité réseau inutile. Restreignez l’accès depuis les segments non fiables tout en préservant le trafic de domaine requis, consignez le périmètre de ce contrôle temporaire et fixez une échéance de correction. C’est une recommandation de réduction de l’exposition, pas une solution de contournement du bug documentée par Microsoft.
6. Transmettez les activités suspectes à la réponse aux incidents. Préservez la télémétrie pertinente et menez l’enquête indépendamment du déploiement des correctifs. L’installation de la mise à jour ne détermine pas si des activités suspectes antérieures impliquaient une compromission.

Notre examen des RCE sur les contrôleurs de domaine d’août 2026 explique pourquoi un inventaire tenant compte des rôles est essentiel pour DNS, AD CS et AD DS. Appliquez cet enseignement opérationnel ici tout en conservant la distinction de la CVE Netlogon de septembre et de sa remédiation propre à chaque produit.

Comment EtcSec détecte ce problème

Pour cette CVE, la vérification de l’exposition doit confronter le niveau réel des correctifs à la correspondance des produits et correctifs Microsoft ci-dessus. La seule posture de configuration ne peut pas répondre à cette question. Cet article n’associe aucun tag de vulnérabilité du collecteur à CVE-2026-72982, car aucune implémentation de détecteur dédié n’a été vérifiée pour ce processus.

Conservez les constats de posture EtcSec aux côtés des preuves de conformité des correctifs, en précisant séparément leur couverture. Un ancien constat relatif à l’application des protections Zerologon, un audit de configuration sans anomalie ou un constat générique sur le système d’exploitation ne doit pas être présenté comme la preuve que cette RCE Netlogon est détectée ou corrigée. Ne clôturez cette CVE qu’avec les preuves de la mise à jour applicable, du build en cours d’exécution et du redémarrage pour chaque serveur affecté.