EN
en direct

Microsoft corrige neuf RCE dans Windows DNS Server, dont un use-after-free à CVSS 9,8

Le Patch Tuesday du 8 septembre 2026 corrige neuf failles d’exécution de code à distance dans Windows DNS Server, dont CVE-2026-69730, un use-after-free à CVSS 9,8 exploitable par un seul paquet forgé. Priorisez la mise à jour des serveurs qui portent le rôle DNS et segmentez le port 53 avant l’apparition d’un exploit public.

Un standard téléphonique mural hérissé de câbles gris identiques, un seul cordon à demi débranché de sa prise, son embout luisant d’un éclat ambre.

8 septembre 2026. Microsoft publie son Patch Tuesday de septembre, et avec lui 964 CVE corrigées — un record qui écrase celui de juillet. Au milieu de ce volume, neuf failles d’exécution de code à distance touchent le rôle DNS Server de Windows. La plus grave, CVE-2026-69730, est un use-after-free au score CVSS 9,8, exploitable par un seul paquet forgé, sans authentification ni interaction. Pourquoi c’est important : un mois après CVE-2026-62878, le débordement de tampon « wormable » corrigé en août, Microsoft comble à nouveau neuf portes d’entrée dans le service réseau le plus exposé de la plupart des parcs.

Un use-after-free qui ne demande qu’un paquet

CVE-2026-69730 est évaluée critique par Microsoft, qui la décrit comme un use-after-free dans Windows DNS. La mécanique est directe : un attaquant non authentifié et distant envoie un paquet spécialement construit au service DNS, et la mémoire libérée est réutilisée avant d’avoir été invalidée — ce qui lui permet de faire exécuter du code arbitraire.

La gravité ne vient pas de la sophistication, mais du profil d’attaque. Les trois propriétés sont réunies en même temps :

  • À distance. L’attaquant n’a besoin d’aucun accès préalable, seulement de la capacité à joindre le serveur sur le port 53.
  • Sans authentification. Aucun identifiant, aucune session, rien à deviner ni à voler au préalable.
  • Sans interaction. Personne n’a à ouvrir quoi que ce soit : le serveur DNS traite le paquet malveillant dans le cadre de son travail ordinaire.

C’est le même trio de propriétés qui, historiquement, transforme une faille en ver. Microsoft a d’ailleurs placé cette CVE dans sa catégorie « exploitation plus probable » plutôt que « moins probable » — un signal rare dans un bulletin mensuel.

Neuf failles, un seul service

CVE-2026-69730 n’est pas isolée. Le même Patch Tuesday corrige huit autres RCE dans le rôle DNS Server. Aucune n’atteint le même niveau d’exploitabilité, mais l’accumulation raconte à elle seule la surface d’attaque.

CVECVSSv3SévéritéÉvaluation Microsoft
CVE-2026-697309,8CritiqueExploitation plus probable
CVE-2026-698138,1CritiqueExploitation moins probable
CVE-2026-698588,1CritiqueExploitation improbable
CVE-2026-775058,1CritiqueExploitation moins probable
CVE-2026-698278,1CritiqueExploitation improbable
CVE-2026-695518,8ImportantExploitation moins probable
CVE-2026-697828,1ImportantExploitation improbable
CVE-2026-699898,1ImportantExploitation improbable
CVE-2026-729287,5ImportantExploitation moins probable

Neuf failles dans un seul composant, c’est un mois inhabituel. C’est aussi un rappel que le rôle DNS Server n’est pas un module accessoire de Windows Server : c’est un service réseau complet, qui parse des entrées non fiables venues de l’extérieur, et qui mérite une revue de sécurité dédiée.

Pourquoi DNS reste le service le plus exposé

Le DNS est le service que presque personne ne segmente vraiment. Le port 53 est ouvert par conception : les résolveurs internes interrogent le serveur, les secondaires répliquent les zones, et dans de nombreux environnements le serveur répond aussi aux requêtes récursives pour tout le parc.

Cette exposition est silencieuse. Un RSSI pressé suit ses CVE d’application et ses appliances, mais le serveur DNS — parce qu’il « fonctionne » — glisse en bas de la pile. Or c’est précisément le type de cible qu’une faille RCE sans authentification transforme en point de pivot : une fois du code exécuté sur le serveur DNS, l’attaquant est déjà au cœur du réseau, sur une machine qui voit passer la résolution de noms de toute l’entreprise.

Le chiffre qui compte n’est pas le CVSS 9,8 seul, c’est le couple « sans authentification + sans interaction ». Il abaisse la barre d’entrée au strict minimum technique : émettre un paquet.

Deux mois de suite : le précédent d’août

Le 11 août 2026, Microsoft corrigeait CVE-2026-62878, un débordement de tampon de pile dans Windows DNS Server, lui aussi à CVSS 9,8 et décrit par les chercheurs comme « wormable ». Le mot mérite d’être précisé : il désigne la forme de la faille — joignable à distance, sans identifiant, sans interaction — et non une propagation constatée. À la date d’écriture, aucune exploitation dans la nature n’a été confirmée pour CVE-2026-62878.

Ce précédent importe pour deux raisons. D’abord, il montre que la vague de septembre n’est pas un accident isolé mais un motif récurrent sur le même composant. Ensuite, il illustre la fenêtre dont disposent les équipes : pour une faille de ce profil, le délai entre la divulgation et l’apparition d’un proof of concept public se compte en jours, pas en semaines. Corriger avant cette fenêtre est toute la différence entre un incident anticipé et une course contre l’exploitation opportuniste.

Ce qu’il faut mettre en place

Quatre actions, par ordre de priorité décroissante :

  • Inventoriez les serveurs qui portent le rôle DNS Server. La faille touche le rôle, pas Windows Server en général. Votre file de correctifs doit commencer par ces machines, pas par l’ensemble du parc.
  • Appliquez la mise à jour cumulative de septembre à ces hôtes en priorité, devant le rythme de déploiement mensuel habituel.
  • Si le correctif ne peut pas être appliqué immédiatement, restreignez l’accès réseau. N’autorisez que les résolveurs secondaires connus et les hôtes d’administration à interroger le serveur, au lieu de laisser le port 53 joignable en large. C’est un pansement, pas un correctif.
  • Surveillez l’apparition d’un exploit public. Dès qu’un proof of concept circule, tout serveur encore non corrigé passe de « à corriger bientôt » à « à corriger aujourd’hui ».

Ajoutez un contrôle périodique qui vérifie que le rôle DNS Server est effectivement couvert par la mise à jour de septembre. La pire configuration n’est pas le serveur non corrigé qu’on connaît, c’est celui qu’on a oublié d’inventorier.

Verdict

Si vous exploitez des contrôleurs de domaine — qui portent presque toujours le rôle DNS — ou tout serveur DNS joignable depuis le réseau, traitez CVE-2026-69730 comme un incident de planification immédiat : elle cumule le score le plus élevé et la probabilité d’exploitation la plus haute d’un bulletin déjà record. Si votre serveur DNS est déjà segmenté et ne répond qu’à des hôtes de confiance, la marge est plus confortable, mais le correctif reste dû avant l’apparition d’un exploit. Dans les deux cas, consignez l’inventaire des serveurs portant le rôle DNS : c’est la seule défense durable contre le prochain bulletin, qui — au rythme actuel — ne devrait pas tarder.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

OpenSSL 4.1 ajoute DTLS 1.3 et GREASE au chiffrement des connexions UDP

Le 9 septembre 2026, la première alpha d’OpenSSL 4.1 active DTLS 1.3 — handshakes raccourcis, forward secrecy et post-quantique intégré — et GREASE, le mécanisme qui empêche les intermédiaires de figer le protocole TLS. Pour tout opérateur de passerelles, d’objets connectés ou de services UDP, c’est le signal de préparer la migration.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer