CVE-2026-62878 : Windows DNS Server wormable CVSS 9.8, vos DC en danger

Les faits

CVE-2026-62878 est une vulnérabilité critique de type stack-based buffer overflow (CWE-121) dans le service DNS Server de Windows. Publiée le 11 août 2026 dans le cadre du Patch Tuesday, elle obtient un score CVSS 9.8 et porte la qualification rare de faille "potentiellement wormable" — autrement dit, une faille dont un exploit pourrait se propager automatiquement de machine en machine sans intervention humaine, sur le modèle de WannaCry (2017) ou de MS17-010 (EternalBlue).

Le service DNS Windows (dns.exe) traite les requêtes DNS entrantes sur les ports 53 UDP et 53 TCP. La vulnérabilité réside dans la validation insuffisante de certains enregistrements DNS lors du traitement de requêtes malformées : un attaquant non authentifié peut envoyer un paquet DNS spécialement construit qui provoque un débordement de pile (stack overflow) dans dns.exe. Ce débordement permet d'écraser le pointeur de retour de la fonction et d'y substituer l'adresse d'un shellcode contrôlé par l'attaquant. Le processus dns.exe s'exécutant avec des privilèges SYSTEM sur Windows Server, l'exécution de code résultante est immédiatement au niveau SYSTEM.

La caractérisation "wormable" par Microsoft dans son bulletin MSRC est l'élément le plus alarmant de cette divulgation. Pour qu'une faille soit qualifiée de wormable, elle doit pouvoir s'auto-propager : un serveur DNS compromis peut envoyer des requêtes DNS forgées vers d'autres serveurs DNS dans l'infrastructure, lesquels deviennent à leur tour des vecteurs d'infection. Dans une architecture d'entreprise typique avec plusieurs DNS resolvers et forwarders, une seule machine initiale compromise pourrait théoriquement compromettre l'ensemble de l'infrastructure DNS en cascade. C'est précisément le mécanisme de WannaCry en 2017 via MS17-010, qui avait paralysé des organisations mondiales en quelques heures.

L'impact dans un déploiement Active Directory standard est particulièrement dévastateur. Dans la majorité des architectures Windows en entreprise, le rôle DNS Server est installé directement sur les contrôleurs de domaine (Domain Controllers). Cette co-localisation est la recommandation historique de Microsoft pour simplifier la gestion des zones DNS intégrées à AD. Mais elle crée un risque majeur : compromettre un serveur DNS revient à compromettre un Domain Controller. Un DC compromis donne accès à NTDS.dit — la base de données de tous les comptes AD — aux hachages de mots de passe de l'ensemble des utilisateurs du domaine, aux secrets Kerberos (krbtgt), et aux GPO. C'est l'équivalent d'une clé maîtresse de toute l'infrastructure d'identité de l'organisation.

L'historique des failles DNS Windows renforce le caractère urgent de la remédiation. CVE-2020-1350, baptisée SIGRed, notée CVSS 10.0 et également wormable, avait ciblé le même composant en juillet 2020 : des exploits fonctionnels avaient été publiés moins de quinze jours après la divulgation. CVE-2021-26897, autre faille DNS Windows CVSS 9.8, avait suivi un calendrier similaire. Microsoft DNS est historiquement un composant à risque élevé de weaponisation rapide, en raison de sa complexité, de son omniprésence et de sa superficie d'attaque via le protocole DNS lui-même.

Les versions affectées documentées par Microsoft incluent : Windows Server 2019 Standard et Datacenter avec le rôle DNS Server activé, Windows Server 2022 dans toutes ses variantes (Standard, Datacenter, Core), et Windows Server 2025. Il est important de noter que la vulnérabilité ne nécessite pas que le serveur DNS soit exposé directement sur Internet pour être exploitée : un accès réseau interne vers le port 53 du serveur DNS suffit. Dans de nombreuses organisations, les DNS internes sont accessibles depuis tous les VLAN et tous les segments réseau, maximisant considérablement la surface d'attaque en cas d'accès initial via un poste de travail compromis ou un accès VPN.

SecurityAffairs et Roboshadow ont rapporté qu'au 17 août 2026, aucune exploitation active n'avait été confirmée dans la nature. La fenêtre de remédiation reste donc ouverte — mais compte tenu du précédent SIGRed et de la caractérisation wormable, cette fenêtre est étroite. Les équipes de sécurité doivent traiter CVE-2026-62878 comme une priorité de remédiation absolue, au même niveau que les patches appliqués en urgence lors des campagnes Log4Shell ou Citrix Bleed.

Un vecteur d'exploitation particulièrement dangereux dans les architectures multi-sites concerne les serveurs DNS forwarders. Ces serveurs transmettent les requêtes qu'ils ne peuvent pas résoudre localement vers des serveurs DNS en amont. Si un forwarder est compromis en premier, il peut envoyer des requêtes malformées vers les DNS parents de l'organisation. A l'inverse, un DNS parent compromis peut envoyer des réponses forgées vers les forwarders en aval. Dans les deux sens, la propagation est possible sans accès direct depuis Internet — ce qui est précisément la définition d'une faille wormable à déploiement interne.

Le fait que dns.exe sur les Domain Controllers soit l'un des processus les plus privilégiés de tout environnement Windows explique pourquoi CVE-2026-62878 doit être traitée en dehors du cycle normal de patch management. Ce n'est pas un patch mensuel parmi 421 autres : c'est un patch qui conditionne l'intégrité de toute l'infrastructure d'identité de l'organisation.

Impact et exposition

Toute organisation utilisant Windows Server pour son infrastructure DNS est potentiellement exposée. L'impact le plus critique concerne les déploiements Active Directory où les Domain Controllers font office de serveurs DNS — compromission DNS égale compromission DC égale prise de contrôle complète du domaine. Les DMZ exposant des serveurs DNS Windows vers Internet augmentent l'exposition externe. Les réseaux internes sans segmentation entre les postes de travail et les serveurs DNS permettent des scénarios de pivot post-compromission de poste de travail.

Recommandations

• Appliquer le patch Microsoft pour CVE-2026-62878 en priorité absolue sur tous les serveurs DNS Windows — commencer par les Domain Controllers
• Séparer le rôle DNS du rôle Domain Controller si l'architecture le permet : déployez des DNS dédiés pour réduire l'impact d'une compromission DNS sur l'infrastructure AD
• Filtrer les connexions DNS (port 53 TCP/UDP) en provenance de segments non autorisés, notamment depuis les postes de travail vers les DNS de production
• Activer le DNS Debug Logging pour détecter des requêtes anormalement structurées dans les logs DNS (Event ID 2, zone transfer anomalies)
• Surveiller les bulletins CERT-FR et MSRC pour les IOC et signatures d'exploitation liés à CVE-2026-62878 dans les prochains jours