Catégorie : Windows Server & Active Directory

Le 13 octobre 2026, Microsoft a corrigé une vulnérabilité qui permet à n’importe quel attaquant présent sur le réseau de ton domaine de viser directement tes contrôleurs — sans identifiants, sans phishing, sans compte compromis au préalable. La faille porte la référence CVE-2026-70229 et touche Active Directory Domain Services (AD DS) lui-même, pas un composant périphérique.

Ce correctif arrive dans un Patch Tuesday particulièrement chargé (1 407 failles corrigées au total selon le récapitulatif d’IT-Connect), mais celle-ci mérite qu’on s’y arrête : elle touche le cœur de ton infrastructure d’identité.

Ce que CVE-2026-70229 permet concrètement

Il s’agit d’un défaut d’autorisation (CWE-863) : AD DS ne vérifie pas correctement les droits d’un demandeur avant de traiter une opération privilégiée. Concrètement, un attaquant non authentifié peut envoyer des paquets réseau spécialement construits à un contrôleur de domaine pour y déclencher une exécution de code, sans identifiants et sans interaction utilisateur. Le vecteur CVSS publié est AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, pour un score de base de 8.1.

Remarque importante sur la gravité : 8.1 place la faille dans la bande « élevée » (High) de l’échelle CVSS, pas dans la bande « critique » (9.0 et au-delà) — même si plusieurs relais de presse la qualifient de « critique » en se basant sur son impact plutôt que sur son score. La nuance vient du AC:H : la complexité d’attaque est haute. Microsoft précise que l’exploitation dépend de conditions réseau et d’un minutage précis, donc ce n’est pas le genre de faille qu’on déclenche en un clic depuis un script trouvé sur GitHub. Pas de preuve de concept publique à ce jour, et le score EPSS (probabilité d’exploitation à 30 jours) tourne autour de 0,71 %, ce qui reste bas.

Ceci dit, AD DS porte Kerberos, LDAP, la réplication et les GPO. Une exécution de code sur un contrôleur de domaine, même difficile à déclencher de façon fiable, ouvre la porte à la falsification de tickets, à la modification de l’appartenance aux groupes et au mouvement latéral vers tous les postes joints au domaine. Le score CVSS mesure la difficulté d’exploitation, pas la gravité de ce qui se passe une fois que ça marche.

Les correctifs par version de Windows Server

Le correctif est inclus dans les mises à jour cumulatives d’octobre, à appliquer en priorité sur tes contrôleurs de domaine avant les serveurs membres :

• Windows Server 2025 — KB5126646, build 26100.33650.
• Windows Server 2022 — KB5126655, build 20348.5761. C’est la dernière mise à jour du cycle de support grand public ; le support continue jusqu’au 14 octobre 2031.
• Windows Server 2019 — KB5126651, build 17763.9376.
• Windows Server 2016 — KB5126868, build 14393.9612. Installe d’abord la mise à jour de la pile de maintenance KB5126649 ; sur WSUS, approuve les deux KB.

Si tu fais encore tourner des contrôleurs de domaine sous Windows Server 2012 ou 2012 R2 : le support étendu (ESU) s’est arrêté exactement le même jour, le 13 octobre 2026. Les derniers correctifs de sécurité jamais publiés pour ces versions sont KB5126835 et KB5126836. Après ça, plus rien — ce Patch Tuesday était littéralement ta dernière fenêtre de rattrapage avant de migrer.

Le reste du lot d’octobre qui concerne tes contrôleurs de domaine

Deux autres changements de cette mise à jour valent le détour, même s’ils sont moins spectaculaires que le RCE non authentifié.

D’abord, la correction de l’ACL du conteneur Distributed Key Manager (DKM) d’AD FS, liée à CVE-2026-56155 — une faille d’élévation de privilèges exploitée comme zero-day et corrigée en juillet 2026. Depuis octobre, le correctif durcit automatiquement les ACL trop permissives sur ce conteneur, sans action de ta part. Si pour une raison précise tu as besoin de désactiver ce durcissement automatique (compatibilité avec un outillage tiers, par exemple), une valeur de registre nommée RemediateDkmAcl permet de l’opter-out — la procédure exacte est documentée dans KB5121391, à consulter avant de toucher à un environnement AD FS en production. C’est le même type d’abus de confiance d’infrastructure PKI/fédération que Certighost (CVE-2026-54121) dans AD CS, dont on parlait la semaine dernière : un composant périphérique de l’écosystème AD qui finit par accorder une confiance qu’il ne devrait pas.

Ensuite, une amélioration du canal sécurisé Netlogon dans KB5126646 : les serveurs membres se connectent plus fiablement aux contrôleurs de domaine déployés avant Windows Server 2025. Utile si tu es en pleine migration et que tu fais tourner des DC de générations mélangées pendant la transition.

Sur Windows Server 2022 et 2019, Microsoft ajoute aussi un audit NTLM avancé qui indique qui utilise encore NTLM, pourquoi il a été sélectionné, et où l’authentification a lieu — pratique pour repérer les dépendances avant le retrait progressif de NTLM.

Limiter l’exposition en complément du correctif

Patcher reste la priorité, mais un contrôleur de domaine joignable depuis n’importe quel poste du réseau reste un risque en soi, faille ou pas :

• Restreins l’accès réseau entrant aux ports d’administration AD (389, 636, 3268, 3269, 88, 445) aux seuls sous-réseaux d’administration légitimes.
• Administre AD DS uniquement depuis des postes d’administration durcis (PAW), jamais depuis un poste utilisateur standard.
• Audite les appartenances aux groupes à privilèges et les changements d’ACL récents ; surveille les ID d’événements 4662, 4670 et 5136.
• Surveille le trafic LDAP, RPC ou DRSUAPI inattendu émis par des hôtes qui ne sont pas des contrôleurs de domaine.

Une règle de pare-feu basique pour limiter l’administration AD à un sous-réseau dédié, à titre d’illustration :

New-NetFirewallRule -DisplayName "AD DS - Sous-reseau admin uniquement" `
  -Direction Inbound -Protocol TCP `
  -LocalPort 389,636,3268,3269,88,445 `
  -RemoteAddress 10.10.0.0/24 -Action Allow

FAQ

Ce correctif est-il vraiment urgent si rien n’est exploité pour l’instant ?
Oui. Le score EPSS bas et l’absence de preuve de concept publique aujourd’hui ne garantissent rien pour demain — l’ACL AD FS corrigée dans cette même mise à jour (CVE-2026-56155) était, elle, un zero-day activement exploité en juillet. Un contrôleur de domaine non patché reste la pire chose à laisser traîner, indépendamment du timing de l’exploitation publique.

La faille est-elle vraiment « critique » comme le disent certains titres ?
Au sens strict de l’échelle CVSS, non : 8.1 correspond à la bande « élevée », pas « critique » (9.0+). La complexité d’attaque haute (AC:H) explique cet écart avec la perception médiatique. Ça ne change rien à la priorité de patch sur tes DC — juste à la façon de présenter le risque si tu dois le justifier en interne.

Le correctif casse-t-il quelque chose en production ?
La page de KB5126646 référence un problème connu lié à WSUS (CVE-2025-59287, une faille RCE distincte). Vérifie les notes de version avant un déploiement en masse si tu administres WSUS en parallèle de tes contrôleurs de domaine.

Je suis encore sur Windows Server 2012 R2, qu’est-ce que je fais ?
Tu appliques KB5126836 maintenant si tu ne l’as pas encore fait — c’est le tout dernier correctif de sécurité jamais publié pour cette version, l’ESU s’est arrêté le 13 octobre 2026. Ensuite, tu planifies la migration sans attendre : il n’y aura plus de filet de sécurité au prochain problème.

En pratique

Patche tes contrôleurs de domaine avant tout le reste de ton parc ce mois-ci, dans cet ordre : DC, puis serveurs membres, puis postes de travail. Si tu gères encore des DC en 2012/2012 R2, c’est le moment de transformer « il faudra migrer un jour » en ticket planifié cette semaine — l’ESU ne reviendra pas te sauver la prochaine fois.

Un compte utilisateur standard, sans le moindre droit d’administration, qui finit par récupérer le hash krbtgt de ton domaine Active Directory. Pas de phishing, pas d’exploit mémoire exotique : juste une requête de certificat mal validée. C’est ce que permet Certighost (CVE-2026-54121), une faille dans Active Directory Certificate Services corrigée par Microsoft en juillet 2026, mais qui reste exploitable sur tous les parcs qui n’ont pas encore appliqué ce correctif précis.

Le détail qui fait mal : le CVSS est de 8,8, pas 9,8 ou 10 comme les failles qui font les gros titres. Mais l’impact, lui, est maximal — une compromission complète du domaine depuis un compte de domaine ordinaire, sans interaction utilisateur. Si tu gères une infrastructure AD CS, cet article t’explique exactement comment ça marche, qui est concerné, et ce que tu dois vérifier dès aujourd’hui.

Le mécanisme de repli qui ne vérifie rien

AD CS prévoit un cas de figure particulier : quand l’autorité de certification (CA) ne parvient pas à récupérer les informations d’identité d’un demandeur auprès du contrôleur de domaine par défaut, elle peut suivre un mécanisme de repli, appelé « chase », vers un autre hôte désigné par la requête elle-même via l’attribut cdc (Client DC). Jusqu’en juillet 2026, la CA contactait cet hôte en SMB (port 445) et LDAP (port 389) sans jamais vérifier qu’il s’agissait réellement d’un contrôleur de domaine du domaine. Elle faisait simplement confiance à ce que le demandeur affirmait.

Concrètement, l’attaque se déroule en six étapes :

• L’attaquant crée un compte machine, en s’appuyant sur le quota par défaut ms-DS-MachineAccountQuota fixé à 10 — accessible à n’importe quel utilisateur de domaine standard — ou réutilise un compte qu’il contrôle déjà.
• Il monte une infrastructure LSA et LDAP falsifiée sur sa propre machine, en écoute sur les ports 445 et 389.
• Il envoie une demande de certificat sur le modèle Machine par défaut, avec l’attribut cdc pointant vers sa propre machine plutôt que vers un vrai contrôleur de domaine.
• La CA suit cet hôte sans vérification et relaie la demande d’authentification via Netlogon vers le véritable contrôleur de domaine, récupérant au passage son objectSid et son dNSHostName.
• Le compte machine contrôlé par l’attaquant fournit alors l’identité valide nécessaire, et la CA émet un certificat qui porte l’identité du contrôleur de domaine ciblé — mais utilisable par le compte de l’attaquant.
• Avec ce certificat, l’attaquant s’authentifie via PKINIT en se faisant passer pour un contrôleur de domaine, puis lance un DCSync pour extraire les secrets du domaine, krbtgt en tête.

Aucune élévation de privilèges locale, aucun malware, aucun clic de l’utilisateur. Juste une CA qui fait confiance à la mauvaise source.

Qui est concerné

Selon la fiche NVD de la CVE, les versions affectées couvrent Windows Server 2012 jusqu’à Windows Server 2025, éditions Server Core incluses, ainsi que Windows 10 version 1607 et 1809. Les chercheurs qui ont publié l’analyse technique (dont Aniq Fakhrul) ont validé leurs tests sur une forêt Windows Server 2016 ou plus récente, avec une CA d’entreprise intégrée à Active Directory en configuration par défaut — exactement la configuration qu’on retrouve dans la majorité des environnements d’entreprise.

La faille a été signalée à Microsoft le 14 mai 2026, confirmée le 22 mai, corrigée le 14 juillet (Patch Tuesday du mois) et divulguée publiquement le 24 juillet. Du code de preuve de concept circule librement sur GitHub depuis cette date. À ce jour, elle ne figure pas dans le catalogue KEV de la CISA et aucune exploitation active confirmée n’a été rapportée publiquement — mais l’historique des failles AD CS (ESC1 à ESC15) montre que ce genre de scénario finit presque toujours par être industrialisé dans des frameworks d’attaque une fois le mécanisme bien documenté, comme ça a été le cas pour BadSuccessor quelques mois plus tôt.

Le correctif de Microsoft, et sa nuance importante

Le patch de juillet ajoute une validation stricte de la cible du mécanisme de repli avant que la CA ne la contacte : rejet des adresses IP brutes, rejet des noms trop longs, filtrage de certains caractères LDAP, et surtout exigence d’un objet ordinateur unique dont l’attribut userAccountControl inclut bien le flag SERVER_TRUST_ACCOUNT (valeur 8192). Une comparaison de SID en sortie bloque ensuite toute substitution d’objet au dernier moment.

Il y a cependant un détail technique à connaître : cette protection passe par un interrupteur de fonctionnalité interne (identifié par les chercheurs comme Feature_3185813818). Si ce flag se retrouve désactivé — configuration héritée, stratégie de groupe particulière, ou simple erreur — le comportement vulnérable d’origine peut potentiellement réapparaître même avec le correctif installé. Ne te contente donc pas de vérifier la présence de la mise à jour de juillet 2026 : vérifie aussi, si tu as un outil de gestion de configuration en place, que ce comportement de validation est bien actif sur tes serveurs AD CS.

Si tu ne peux pas patcher immédiatement

Pour les serveurs où le correctif ne peut pas être déployé tout de suite — fenêtre de maintenance à planifier, validation de changement en cours — il existe un contournement temporaire : désactiver le drapeau EditFlags qui active le chase côté CA.

certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC
Restart-Service CertSvc -Force

Attention : ce contournement n’a été validé qu’en laboratoire par les chercheurs à l’origine de la découverte, pas par Microsoft lui-même. Il peut casser des flux d’inscription de certificats légitimes qui dépendent justement de ce mécanisme de repli, notamment dans les environnements multi-forêts ou multi-sites avec de la latence réseau entre contrôleurs de domaine. Teste-le d’abord en pré-production, sur un CA de test, avant d’y toucher en production.

Pour les systèmes qui ne reçoivent plus de mises à jour officielles (Windows Server 2008 R2, 2012 et 2012 R2 en fin de support), 0patch a publié des micropatches logiquement identiques au correctif Microsoft, appliqués sans redémarrage sur les machines qui disposent de l’agent.

Détecter une tentative d’exploitation

Microsoft Defender signale les requêtes malveillantes sous deux alertes dédiées : « Potential Certighost (CVE-2026-54121) AD CS abuse » et « Active Directory Certificate Services attack tool activity ». Si tu n’as pas Defender for Identity déployé sur tes serveurs AD CS, trois réflexes à adopter dès cette semaine :

• Active l’audit des services de certificats (succès et échecs) sur la CA, et configure le filtre d’audit pour couvrir les événements de cycle de vie des certificats.
• Surveille les événements de sécurité 4886 et 4887 (demande de certificat et émission) à la recherche de volumes ou de patterns inhabituels, en particulier des émissions issues du modèle Machine qui portent des données d’identité de contrôleur de domaine inattendues.
• Audite la valeur de ms-DS-MachineAccountQuota sur ton domaine — la valeur par défaut de 10 autorise n’importe quel utilisateur standard à créer jusqu’à dix comptes machine, ce qui est la première brique de cette attaque (et de pas mal d’autres). La ramener à 0 pour les utilisateurs non-admin, avec des exceptions ciblées via délégation, ferme cette porte sans casser les joiners légitimes gérés par un compte de service dédié.

Pour un audit plus poussé de ta hiérarchie PKI, l’outil open source PSPKIAudit (cité par plusieurs analyses de la faille) permet de repérer les templates de certificats mal configurés et les CA exposées à ce type de scénario de relais, dans la même veine que les vulnérabilités ESC1 à ESC15 déjà documentées.

Pourquoi un 8.8 mérite autant d’attention qu’un 9.8

On a tendance à classer les priorités de patch par score CVSS brut, et à reléguer un 8.8 derrière les zero-days à 9.8 ou 10 qui font la une des bulletins mensuels. C’est une erreur dans ce cas précis. Un 9.8 typique touche souvent un service exposé qu’on peut isoler ou filtrer en attendant le correctif. Certighost, lui, touche le cœur de confiance de ton infrastructure d’identité, depuis un compte de domaine banal, sans qu’aucune segmentation réseau classique ne t’en protège — si l’utilisateur a accès au réseau du contrôleur de domaine et de la CA, l’attaque est jouable. Le score reflète la complexité d’exploitation (il faut une CA d’entreprise, un modèle Machine accessible, et une connectivité SMB/LDAP spécifique), pas la gravité du résultat une fois l’attaque réussie.

FAQ

Faut-il désactiver AD CS en attendant de tout vérifier ?

Non, ce serait disproportionné pour la quasi-totalité des environnements. Priorise la vérification du patch de juillet 2026 sur tes serveurs AD CS, et si ce n’est pas possible immédiatement, applique le contournement EditFlags après test en pré-production.

Un pare-feu entre les sites suffit-il à me protéger ?

Seulement si l’attaquant n’a pas accès réseau à la fois à la CA et au vrai contrôleur de domaine. Dans la plupart des topologies d’entreprise avec des contrôleurs de domaine accessibles depuis le réseau utilisateur, ce n’est pas une protection suffisante — le patch ou le contournement reste nécessaire.

Le correctif de juillet 2026 est-il inclus dans les mises à jour cumulatives suivantes ?

Oui, comme tout correctif de sécurité Windows, il est intégré aux cumulative updates ultérieures. Si tu es à jour sur ton Patch Tuesday depuis juillet 2026, tu l’as déjà. L’enjeu réel pour la plupart des équipes est de vérifier les serveurs AD CS isolés ou en retard de patch, pas les postes clients.

Comment savoir si le flag Feature_3185813818 est actif chez moi ?

Microsoft n’a pas publié de commande officielle pour l’interroger directement à ce jour. Le plus fiable reste un test fonctionnel en environnement de pré-production : tenter de reproduire le scénario d’attaque documenté par les chercheurs et vérifier que la demande de certificat est bien rejetée après le patch de juillet.

En pratique, cette semaine

Vérifie que tes serveurs AD CS ont bien reçu la mise à jour de juillet 2026, audite ta valeur de ms-DS-MachineAccountQuota, et active l’audit des événements 4886/4887 si ce n’est pas déjà fait. Trois actions concrètes, aucune ne demande de fenêtre de maintenance longue, et elles réduisent une surface d’attaque qui touche directement krbtgt — le cœur de la confiance Kerberos de ton domaine, le même mécanisme qui a justifié la bascule forcée de RC4 vers AES quelques semaines plus tôt.

Windows Server 2025 a introduit les delegated Managed Service Accounts (dMSA), pensés pour migrer en douceur les comptes de service hérités. On avait couvert les principaux changements sécurité de cette version pour Active Directory dans cet article — les dMSA n’y figuraient pas encore comme un risque, et c’est justement le sujet du jour. Quelques mois après leur sortie, le chercheur Yuval Gordon (Akamai) a montré qu’ils ouvraient une voie d’élévation de privilèges vers n’importe quel compte du domaine — y compris un Domain Admin — sans toucher à un seul contrôleur de domaine. Le nom retenu : BadSuccessor.

Microsoft a corrigé la faille originale (CVE-2025-53779) lors d’un Patch Tuesday d’août 2025 qui corrigeait 107 CVE au total. Le problème : le correctif ferme une porte, pas la pièce entière. Une variante post-patch reste exploitable aujourd’hui, et si tu as un seul contrôleur de domaine Windows Server 2025 dans ton environnement, ça te concerne directement.

Pourquoi un simple droit sur une OU suffisait à devenir Domain Admin

Un dMSA référence le compte qu’il remplace via l’attribut msDS-ManagedAccountPrecededByLink. Avant le correctif, le KDC construisait le PAC (Privilege Attribute Certificate) du dMSA à partir de ce seul attribut, sans vérifier que le lien était réciproque. Concrètement : si tu pouvais créer un dMSA — ce qui ne demande que le droit CreateChild sur une unité d’organisation — tu pouvais le faire pointer vers n’importe quel compte, récupérer ses privilèges effectifs et ses clés Kerberos dès l’authentification suivante.

Le chiffre qui donne la mesure du problème : selon l’analyse d’Akamai, 91 % des environnements Active Directory examinés accordaient ce droit CreateChild à au moins un utilisateur hors Domain Admins sur au moins une OU. Autrement dit, la plupart des forêts avaient déjà, sans le savoir, la précondition réunie.

Ce que le correctif a réellement changé

Le patch agit dans kdcsvc.dll : le KDC exige désormais un appairage mutuel au moment de l’émission du ticket. Le compte cible doit lui aussi référencer le dMSA en retour, via les attributs msDS-SupersededManagedAccountLink et msDS-SupersededServiceAccountState. Un lien à sens unique — celui que BadSuccessor original exploitait — ne produit plus de ticket. L’escalade directe, sans aucun droit sur le compte cible, est fermée.

La variante qui survit : forger l’appairage

Ces nouveaux attributs ne sont pas protégés en écriture. Si tu disposes à la fois de CreateChild sur une OU et de GenericWrite sur le compte cible, tu peux écrire toi-même les deux côtés du lien et obtenir un appairage valide aux yeux du KDC. Résultat : tu t’authentifies en tant que dMSA et récupères le paquet de clés contenant les clés Kerberos du compte cible.

C’est présenté comme une alternative ciblée au DCSync classique — sans passer par l’interface de réplication DRS, donc sans les signatures de détection habituelles associées à une réplication anormale. Deux risques résiduels concrets, donc : l’obtention d’identifiants via appairage forgé, et l’extraction de secrets dans un domaine déjà partiellement compromis.

Comment détecter une tentative

Avant même de promouvoir ton premier contrôleur de domaine Windows Server 2025, active l’audit « Audit Directory Service Changes » (sous-catégorie DS Access) sur l’ensemble de tes DC, et pose des SACL sur les objets dMSA. Les événements à surveiller :

• 5137 — création d’un dMSA
• 5136 — modification d’un attribut sur un objet existant
• 2946 et 4768/4769 — émission de TGT/TGS pour un dMSA
• 4662 — solution de repli si les événements ci-dessus ne sont pas disponibles, mais à filtrer impérativement par GUID de schéma pour éviter une surcharge de ton SIEM

Cinq attributs méritent une surveillance dédiée : msDS-GroupMSAMembership, msDS-ManagedAccountPrecededByLink, msDS-SupersededManagedAccountLink, msDS-SupersededServiceAccountState et msDS-DelegatedMSAState. L’enjeu réel n’est pas de repérer un dMSA isolé — c’est de corréler, dans une fenêtre de quelques minutes, la séquence création → appairage → authentification, en tenant compte du décalage horaire entre contrôleurs de domaine. Si tu veux revoir comment Kerberos a évolué sur tes DC cette année, on avait couvert la bascule RC4 dans cet article.

Ce qu’il faut faire, dans l’ordre

D’abord, vérifie que le correctif d’août 2025 est appliqué sur tous tes contrôleurs de domaine — ça ferme la voie d’escalade la plus simple, sans aucune précondition sur le compte cible. Ensuite, et c’est le point que la plupart des équipes négligent : traite les dMSA comme du matériel d’identité Tier 0. Audite les délégations CreateChild sur tes OU avec BloodHound, retire ce droit à tout compte qui n’en a pas explicitement besoin, et fais le même ménage sur les GenericWrite superflus sur tes comptes sensibles.

Le correctif Microsoft referme une porte spécifique. Les permissions ACL de ton annuaire restent, elles, la vraie barrière — et c’est celle qui ne se corrige pas avec un Patch Tuesday.

FAQ

Suis-je concerné si je n’utilise pas encore les dMSA ?

Le risque apparaît dès qu’un contrôleur de domaine Windows Server 2025 est promu dans ton domaine, même si tu n’as créé aucun dMSA volontairement — l’évaluation se fait domaine par domaine, pas à l’échelle de la forêt entière.

Le correctif d’août 2025 est-il suffisant à lui seul ?

Il ferme l’escalade originale sans précondition sur la cible, ce qui est déjà la partie la plus dangereuse. Mais la variante à appairage forgé reste possible si les permissions CreateChild/GenericWrite ne sont pas resserrées.

Comment repérer les droits CreateChild à risque sur mes OU ?

BloodHound reste l’outil de référence pour cartographier ce type de délégation ; combine-le avec un audit SACL avant de promouvoir ton premier DC Windows Server 2025, pas après.

Prochaine étape

Si tu as déjà des contrôleurs de domaine Windows Server 2025, vérifie dès aujourd’hui la présence du correctif CVE-2025-53779 sur chacun d’eux, puis lance un audit BloodHound des droits CreateChild sur tes OU. C’est le genre de chantier qu’on repousse facilement — jusqu’au jour où un pentest ou un incident le fait remonter à ta place.

Un seul paquet réseau forgé, aucune authentification, aucune interaction utilisateur — et potentiellement une exécution de code sur ton contrôleur de domaine. C’est le résumé de CVE-2026-69730, une faille use-after-free dans le rôle DNS Server de Windows, corrigée lors du Patch Tuesday de septembre 2026. Score CVSS : 9.8 sur 10. Et ce n’était pas un cas isolé ce mois-là.

CVE-2026-69730 : ce qu’il faut savoir

La faille (type CWE-416, use-after-free) touche le service DNS Server de Windows. Microsoft l’a publiée le 8 septembre 2026 avec une note d’exploitabilité « Exploitation More Likely » — autrement dit, Microsoft juge qu’une exploitation est probable, sans pour autant confirmer à ce stade une exploitation active constatée dans la nature. Le vecteur d’attaque est réseau, la complexité d’exploitation faible, et aucun privilège ni interaction utilisateur n’est requis côté victime : un attaquant envoie un paquet DNS malveillant, et c’est terminé.

Le problème de fond, c’est que le rôle DNS Server tourne très souvent sur les mêmes machines que les contrôleurs de domaine — Microsoft le recommande même historiquement pour simplifier la réplication des zones intégrées à Active Directory. Résultat : une faille « DNS », qui pourrait sembler périphérique, ouvre en réalité une porte directe sur l’infrastructure d’identité de l’entreprise. Ce n’est pas LDAP, ce n’est pas Kerberos, mais l’impact potentiel est identique.

Le plus gros Patch Tuesday de l’histoire de Microsoft

CVE-2026-69730 n’arrive pas seule. Le lot de septembre 2026 a corrigé 964 CVE au total — 104 classées critiques, 860 importantes — ce qui en fait, selon Tenable, le plus volumineux Patch Tuesday jamais publié par Microsoft. Deux failles zero-day distinctes (non liées au DNS) étaient par ailleurs activement exploitées dans ce même lot, ce qui a probablement capté une bonne partie de l’attention médiatique au détriment des failles DNS et Kerberos qu’on détaille ici.

Le DNS Windows n’a d’ailleurs pas été touché par une seule faille isolée ce mois-là : CVE-2026-69551 (CVSS 8.8), CVE-2026-69813, CVE-2026-69858 et CVE-2026-77505 (CVSS 8.1 chacune) corrigent d’autres vulnérabilités dans le même composant. Si tu administres des DC avec rôle DNS intégré, ce n’est pas un correctif à traiter isolément — c’est un paquet de durcissement à appliquer en bloc.

Et Kerberos n’est pas épargné non plus

Dans le même Patch Tuesday, CVE-2026-69676 touche Windows Kerberos : score CVSS 8.8, exécution de code à distance via une attaque par rejeu d’authentification (authentication bypass by capture-replay). Un attaquant disposant d’un accès réseau de bas niveau — pas besoin d’être déjà authentifié sur le domaine — peut en théorie l’exploiter. Microsoft a mis à jour l’avis le 24 septembre 2026, ce qui suggère un ajustement après la publication initiale (périmètre ou détails techniques affinés). Si le sujet Kerberos t’intéresse, on avait déjà couvert la bascule RC4 vers AES sur Kerberos plus tôt ce mois-ci — deux failles différentes, mais le même composant qui continue d’accumuler les correctifs en 2026.

Comment vérifier ton exposition

Avant de paniquer sur l’ensemble du parc, commence par identifier où le rôle DNS Server est réellement installé :

# Sur chaque contrôleur de domaine ou serveur Windows Server
Get-WindowsFeature -Name DNS | Where-Object Installed

# Vérifier le niveau de correctif installé
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

Si le rôle DNS n’est pas installé sur une machine donnée, cette CVE précise ne la concerne pas — mais vérifie quand même les autres correctifs du même lot (Kerberos notamment, qui touche potentiellement tout DC, avec ou sans DNS).

Comment patcher sans tout casser

Rien d’exotique ici : la mise à jour cumulative de septembre 2026 corrige l’ensemble de ces CVE. La vraie question, c’est la rapidité de déploiement. Si ton parc est encore piloté via WSUS, on avait détaillé les limites actuelles de WSUS et les alternatives recommandées par Microsoft (Windows Autopatch pour les postes, Azure Update Manager pour les serveurs) — un contexte qui prend un relief particulier quand le correctif à pousser porte justement sur une CVSS 9.8 touchant l’infrastructure DNS/AD. Pour un DC en particulier, le délai entre « patch disponible » et « patch appliqué » ne devrait jamais dépasser le cycle de maintenance hebdomadaire standard, et certainement pas pour une faille de cette gravité.

FAQ

CVE-2026-69730 est-elle activement exploitée ?

Au moment de la publication par Microsoft, l’éditeur qualifiait l’exploitation de « plus probable » sans confirmer d’exploitation active constatée pour cette CVE spécifique — à distinguer des deux zero-days (autres CVE) confirmés exploités dans le même lot de septembre. Vérifie le MSRC Update Guide pour le statut le plus à jour avant de prioriser ton plan de remédiation.

Dois-je désactiver le rôle DNS sur mes DC en attendant de patcher ?

Dans la grande majorité des environnements Active Directory, non — le DNS intégré AD est généralement indispensable au fonctionnement normal du domaine (localisation des contrôleurs, réplication). La bonne réponse ici est la rapidité de patch, pas la désactivation du service.

Cette faille touche-t-elle aussi les serveurs DNS non liés à Active Directory ?

Oui, tout serveur Windows avec le rôle DNS Server installé est potentiellement concerné, qu’il serve ou non de contrôleur de domaine. Le risque est simplement plus élevé quand DNS et AD DS cohabitent sur la même machine, puisqu’une compromission touche alors directement l’annuaire.

En résumé

Une CVSS 9.8 sans authentification requise sur un service aussi structurant que le DNS mérite un traitement prioritaire, pas une ligne de plus dans un ticket de maintenance mensuel. Si tes contrôleurs de domaine hébergent le rôle DNS — ce qui est le cas de la majorité des déploiements AD classiques — vérifie ton niveau de correctif dès aujourd’hui plutôt que d’attendre la prochaine fenêtre de maintenance planifiée.

Sources officielles : analyse détaillée de Tenable sur le Patch Tuesday de septembre 2026, résumé et fiche CVE par Action1, et le MSRC Update Guide pour le détail officiel par produit et build.

Le 8 septembre 2026, la Zero Day Initiative a publié sa revue mensuelle des correctifs Microsoft. Pas une ligne sur Kerberos. Et pourtant, c’est le mois où la dernière phase d’un changement lancé en janvier est censée être derrière toi depuis juillet : la fin du repli automatique sur RC4 dans Active Directory. Si tu n’as pas suivi le dossier de près, il y a de bonnes chances qu’un ou deux comptes de service chez toi authentifient encore en RC4-HMAC sans que personne s’en soit rendu compte — jusqu’au jour où un client Windows patché refuse purement et simplement le ticket.

CVE-2026-20833, ou pourquoi RC4 devait sauter

Le sujet n’est pas nouveau. Depuis les correctifs de novembre 2022 liés à CVE-2022-37966, Windows préfère AES-SHA1 par défaut pour les comptes sans msDS-SupportedEncryptionTypes explicite. Mais « préférer » n’est pas « imposer » : tant qu’un compte ne supportait pas AES, le KDC continuait à délivrer du RC4-HMAC sans broncher. Cette tolérance est exactement ce qu’exploite le Kerberoasting — un attaquant demande un ticket de service, l’extrait, et le casse hors ligne parce que RC4 se prête bien mieux au brute-force qu’AES256.

CVE-2026-20833 formalise ce risque résiduel et pousse Microsoft à couper le filet de sécurité : le repli implicite sur RC4 devait être désactivé par défaut sur les contrôleurs de domaine d’ici la fin du deuxième trimestre 2026. Ce n’est plus une recommandation, c’est un calendrier avec des dates de bascule fixées dans les correctifs de sécurité mensuels.

Trois phases, et la troisième ne se rembobine pas

Le déploiement a suivi un rythme volontairement progressif, en trois temps :

• Janvier 2026 — mode audit. Aucune authentification ne casse. Les événements 4768/4769 se mettent à journaliser le type de chiffrement utilisé pour chaque demande de ticket, ce qui te donne enfin une visibilité réelle sur qui utilise encore RC4 dans ton annuaire.
• Avril 2026 — application avec filet de rattrapage. Le KDC passe en mode AES-only pour tout compte dont msDS-SupportedEncryptionTypes n’est pas défini. Tu peux encore configurer explicitement RC4 sur un compte précis pour gagner du temps, le temps de migrer proprement.
• Juillet 2026 — application définitive. Le mode audit et la possibilité de rollback disparaissent. RC4 ne fonctionne plus que si tu l’as explicitement autorisé compte par compte, ce qui reste fortement déconseillé.

Nous sommes fin septembre : la phase 3 est derrière nous depuis deux mois. Si un service authentifie encore silencieusement en RC4 sur un compte que personne n’a remis à niveau, ce n’est plus une fenêtre de tir qui se referme — c’est déjà fermé, et la panne surviendra au prochain redémarrage de service, à la prochaine rotation de mot de passe, ou dès qu’un client durci rejoindra le domaine.

Comment savoir si tu es exposé, concrètement

Pas besoin de deviner. La méthode documentée par Microsoft passe par les journaux d’événements Kerberos :

Get-ADObject -Filter "Name -eq 'nomducompte' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')" `
    -Properties "msDS-SupportedEncryptionTypes" |
    Format-List DistinguishedName, msDS-SupportedEncryptionTypes, Name, ObjectClass

Une valeur de 28 (0x1C en hexadécimal) signifie RC4 + AES128 + AES256 encore acceptés. Tu veux arriver à 24 (0x18) — AES128 et AES256 uniquement, RC4 explicitement exclu. Si l’attribut n’est pas défini du tout, le KDC retombe sur DefaultDomainSupportedEncTypes, une clé de registre sous HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC — un cas plus délicat à traiter parce qu’il touche potentiellement tout le domaine d’un coup plutôt qu’un compte isolé.

Pour repérer les échecs déjà en cours plutôt que d’attendre les tickets, l’outil de diagnostic le plus direct reste klist en ligne de commande :

klist get HOST/serveur.contoso.com

Un message 0xc00002fd avec le texte « The encryption type requested is not supported by the KDC » ne laisse aucune ambiguïté : le compte cible n’a pas les clés AES nécessaires. Le correctif le plus simple, quand c’est un compte utilisateur ou une machine plutôt qu’un compte de service historique, est souvent de simplement réinitialiser le mot de passe — ça régénère les clés AES-SHA1 manquantes sans toucher à quoi que ce soit d’autre.

Le cas particulier de Microsoft Entra Domain Services

Si tu exploites un domaine géré via Microsoft Entra Domain Services, la même logique s’applique côté cloud, avec une alerte dédiée : AADDS123 — Kerberos RC4 usage detected for service ticket issuance. Le principe de résolution est identique — désactiver RC4 dans les paramètres de sécurité du domaine managé, activer les audits de sécurité, surveiller les événements 4768/4769 — à un détail près : pour un compte de service synchronisé depuis un AD on-premises via Microsoft Entra Connect qui a temporairement besoin de RC4, c’est l’attribut msDS-SupportedEncryptionTypes côté AD local qu’il faut modifier, la valeur se synchronisant ensuite vers le domaine managé. L’état de santé du domaine se met à jour automatiquement sous deux heures une fois la dépendance corrigée.

Ce qui casse en pratique (et ce qui ne prévient pas avant)

Deux scénarios reviennent le plus souvent dans les tickets de support après une bascule AES-only mal préparée. Le partage SMB qui refuse soudain la connexion, avec une simple boîte de dialogue d’erreur réseau côté client — sans détail exploitable sans creuser côté serveur. Et la session PowerShell distante via New-PSSession, qui échoue silencieusement parce que WMI s’appuie sur le même mécanisme d’authentification. Dans les deux cas, le réflexe à avoir est le même : lancer klist pour confirmer que le problème vient bien d’un type de chiffrement non supporté, plutôt que de partir sur une fausse piste réseau ou pare-feu.

Il y a un piège classique à éviter : penser qu’un compte utilisateur sans SPN (Service Principal Name) a besoin d’un msDS-SupportedEncryptionTypes configuré. Ce n’est pas le cas — c’est la configuration de l’appareil qui détermine le type de chiffrement pour les demandes de tickets de service et les clés de session, pas celle du compte utilisateur lui-même. Perdre du temps à modifier cet attribut sur des centaines de comptes utilisateurs alors que le vrai problème vient de trois comptes de service oubliés, ça arrive plus souvent qu’on ne le pense.

FAQ

RC4 est-il complètement supprimé de Windows en 2026 ?

Non. Il reste utilisable, mais uniquement si tu le configures explicitement compte par compte (valeur 0x1C ou proche sur msDS-SupportedEncryptionTypes). Ce qui a disparu en juillet 2026, c’est le repli automatique et silencieux vers RC4 quand rien n’est configuré.

Comment auditer sans casser la production ?

Active les catégories d’audit « Kerberos Authentication Service » et « Kerberos Service Ticket Operations » via une stratégie de groupe, puis corrèle les événements 4768/4769 sur tes contrôleurs de domaine. C’est en lecture seule — aucun risque d’interrompre une authentification en cours.

Et si je découvre la dépendance RC4 seulement maintenant, en septembre ?

Tu peux temporairement réautoriser RC4 sur le compte concerné en fixant msDS-SupportedEncryptionTypes à une valeur qui l’inclut (0x1C par exemple), le temps de traiter la cause racine — généralement une application legacy ou un compte de service jamais réinitialisé depuis des années. Ce n’est pas un rollback de la politique KDC elle-même, juste une dérogation ciblée.

Ce qu’il faut retenir

Le plus gros risque n’est pas technique, il est organisationnel : découvrir la dépendance RC4 le jour où un applicatif métier tombe, plutôt qu’en amont via les journaux d’événements. Si tu n’as jamais lancé l’audit sur tes contrôleurs de domaine, c’est le moment de le faire — la fenêtre de tolérance, elle, est close depuis juillet. Pour le reste de ta feuille de route sécurité Windows Server, notre article sur la faille critique WSUS de 2026 et celui sur les changements de sécurité Active Directory dans Windows Server 2025 couvrent les deux autres chantiers qui méritent ta priorité ce trimestre.

Tu as peut-être laissé WSUS tourner en arrière-plan depuis des années, sans trop y toucher : ça patchait, ça marchait, pas de raison de changer. Sauf qu’en octobre 2025, une faille critique non authentifiée a rappelé à tout le monde que « déprécié » ne veut pas dire « sans risque ». Dans cet article, tu as le point complet sur l’état réel de WSUS en 2026 : ce qui s’est passé avec la CVE-2025-59287, ce que « déprécié » signifie concrètement pour ton parc, et surtout les alternatives à envisager selon tes machines — postes Windows, serveurs, ou environnement ConfigMgr.

Ce qui s’est passé : la CVE-2025-59287

Le 14 octobre 2025, Microsoft publie un correctif dans le cadre du Patch Tuesday pour une vulnérabilité de désérialisation de données non fiables dans le rôle serveur WSUS. Quelques jours plus tard, il devient clair que ce correctif initial est insuffisant : Microsoft doit publier un correctif hors bande le 23 octobre 2025 pour combler la faille pour de bon.

Le problème est sérieux à plusieurs titres :

• Elle permet une exécution de code à distance sans authentification, en envoyant un événement forgé au service WSUS.
• Elle note 9.8 sur 10 à l’échelle CVSS — quasiment le score maximal.
• Des campagnes d’exploitation active ont été observées avant même la sortie du correctif définitif, ciblant les ports par défaut 8530 et 8531, avec des scripts PowerShell malveillants exécutés via les processus worker IIS pour extraire des informations réseau et de domaine.
• Un exploit public (PoC) a circulé, et la vulnérabilité a été ajoutée au catalogue Known Exploited Vulnerabilities de la CISA.

Si tu gères encore un serveur WSUS exposé, la priorité absolue est de vérifier que le correctif hors bande d’octobre 2025 est bien installé, puis de t’assurer que le rôle n’est pas accessible depuis Internet sans filtrage :

# Vérifier si le correctif hors bande d'octobre 2025 est présent
Get-HotFix | Where-Object { $_.HotFixID -match "KB5070882|KB5070883|KB5070884" }

# Vérifier que WSUS n'écoute pas sur une interface exposée publiquement
Get-NetTCPConnection -LocalPort 8530,8531 | Select-Object LocalAddress, State, OwningProcess

WSUS en 2026 : où en est vraiment la dépréciation ?

Microsoft a annoncé la dépréciation de WSUS le 20 septembre 2024. Concrètement, ça veut dire que le rôle n’est plus en développement actif — pas de nouvelle fonctionnalité, pas d’évolution — mais il continue d’être livré avec Windows Server 2025, reste supporté en production, et reçoit les correctifs de sécurité et de qualité selon le cycle de vie du produit, comme le confirme la documentation officielle Microsoft Learn.

En pratique, WSUS hérite donc du cycle de vie de Windows Server 2025, ce qui repousse son support jusqu’en octobre 2034 pour le support étendu — c’est le seul horizon que Microsoft s’est engagé à tenir jusqu’ici. Ça te laisse du temps, mais ce n’est pas une raison pour ne rien faire : un composant qui ne reçoit plus d’investissement actif reçoit aussi moins d’attention défensive, comme l’a montré cette CVE critique un an à peine après l’annonce de dépréciation.

Autre point à connaître si tu es dans un environnement Configuration Manager : le rôle Software Update Point (SUP) de ConfigMgr n’est officiellement pas affecté par la dépréciation, mais il continue de dépendre d’une installation WSUS locale pour fonctionner. Microsoft n’a annoncé aucun découplage à ce jour.

Faut-il migrer maintenant ? Les alternatives selon ton parc

Postes Windows 10/11 : Windows Update for Business + Intune + Autopatch

Pour les postes de travail, la trajectoire recommandée par Microsoft passe par Windows Autopatch, orchestré via Microsoft Intune et les stratégies Windows Update for Business. Si tu es encore sous ConfigMgr, le co-management te permet de basculer progressivement la charge de travail « mises à jour Windows » vers Intune sans devoir migrer tout ton parc d’un coup — tu déplaces juste ce curseur-là, le reste continue de fonctionner comme avant.

L’arrivée de l’Intune Suite dans les licences M365 E3/E5 rend cette trajectoire moins coûteuse qu’avant : ce que le bundling change pour toi.

Serveurs Windows et Linux : Azure Update Manager

Pour tes serveurs, Azure Update Manager (AUM) centralise l’évaluation et le déploiement des correctifs, sur Azure comme en hybride via Azure Arc. Ce qui est intéressant, c’est que ça peut ne rien te coûter en plus dans plusieurs cas de figure, d’après la FAQ tarifaire officielle :

• Tes VM sont directement dans Azure : gratuit.
• Tu as Microsoft Defender for Servers Plan 2 activé sur l’abonnement.
• Tes serveurs bénéficient d’Extended Security Updates via Azure Arc.
• Tes licences Windows Server ont une Software Assurance active, ou tu utilises le pay-as-you-go Windows Server via Arc.

Hors de ces cas, la facturation est au jour et par serveur Arc-enabled connecté — vérifie ta situation avant de basculer un parc entier.

Environnement ConfigMgr : pas de sortie de secours immédiate

Si le Software Update Point reste ton mode de distribution principal, WSUS reste architecturalement nécessaire tant que tu n’abandonnes pas l’orchestration des correctifs par Configuration Manager. La bascule vers le cloud se fait alors workload par workload, via le co-management, plutôt qu’en une migration unique.

Si tu restes sur WSUS pour l’instant : la checklist minimale

Migrer prend du temps, et ce n’est pas toujours la priorité de cette semaine. En attendant, voici ce qui t’évite de rester exposé sur une faille déjà exploitée activement :

• Confirme l’installation du correctif hors bande d’octobre 2025 sur tous tes serveurs WSUS, pas seulement le principal.
• Vérifie qu’aucun serveur WSUS n’expose les ports 8530/8531 directement sur Internet — c’est le vecteur observé dans les campagnes d’exploitation.
• Surveille les journaux IIS pour des exécutions PowerShell inhabituelles issues du processus worker (w3wp.exe) hébergeant WSUS.
• Segmente le réseau autour du serveur WSUS comme n’importe quel système avec des privilèges élevés sur ton parc.

Pour t’entraîner à prioriser, reprends le Patch Tuesday de septembre 2026 et ses deux zero-days.

FAQ

WSUS va-t-il être supprimé de Windows Server ?

Pas à court terme. Le rôle reste livré et supporté jusqu’à la fin du support étendu de Windows Server 2025, soit octobre 2034. « Déprécié » signifie ici « plus de nouvelles fonctionnalités », pas « retiré ».

Azure Update Manager est-il vraiment gratuit ?

Ça dépend de ta situation : gratuit pour les VM Azure natives, et gratuit pour les serveurs Arc-enabled dans plusieurs cas (Defender for Servers Plan 2, Software Assurance, ESU via Arc). Sinon, c’est une facturation journalière par serveur connecté.

Dois-je migrer en urgence à cause de cette CVE ?

Le correctif d’octobre 2025 traite la vulnérabilité elle-même — s’il est installé, le risque immédiat est couvert. Mais l’épisode illustre bien pourquoi il vaut mieux planifier ta sortie de WSUS plutôt que d’attendre la prochaine alerte.

ConfigMgr peut-il se passer complètement de WSUS ?

Pas aujourd’hui. Le Software Update Point reste dépendant d’une installation WSUS locale, et Microsoft n’a pas annoncé de découplage.

Ce qu’il faut retenir

WSUS n’a pas disparu et ne disparaîtra pas cette année — mais son statut « déprécié » se traduit concrètement par moins d’investissement défensif, comme la CVE-2025-59287 vient de le démontrer. Si tu ne l’as pas encore fait, profite de ce signal pour cartographier tes machines encore rattachées à WSUS et planifier leur bascule vers Windows Autopatch ou Azure Update Manager selon leur profil. Et si tu dois rester dessus encore quelques mois, commence au minimum par vérifier que le correctif d’octobre 2025 est bien en place partout.

Si tu gères des serveurs RDS (Bureau à distance) sous Windows Server 2019, 2022 ou 2025, tu as peut-être passé une mauvaise semaine mi-septembre. Les mises à jour du Patch Tuesday du 8 septembre 2026 ont introduit une régression sérieuse : connexions qui restent bloquées, sessions impossibles à fermer proprement, et dans les cas les plus sévères, des serveurs qu’il fallait redémarrer à froid pour retrouver un état stable. Microsoft a mis six jours à publier un correctif d’urgence. Voici ce qu’il s’est passé, comment vérifier si tu es concerné, et surtout comment appliquer le correctif sans attendre le prochain cycle de mises à jour.

Ce qui s’est cassé avec le Patch Tuesday de septembre

Les mises à jour de sécurité du 8 septembre 2026 ont touché trois versions de Windows Server :

• Windows Server 2019 — KB5122876
• Windows Server 2022 — KB5122882
• Windows Server 2025 — KB5122871

Sur les serveurs avec le rôle Remote Desktop Services actif, le symptôme se manifestait progressivement : les connexions fonctionnaient normalement les premières heures, puis se dégradaient. De nouvelles tentatives de connexion restaient bloquées, les sessions existantes n’arrivaient plus à se déconnecter ou à se fermer proprement, et dans les situations les plus critiques, seul un redémarrage forcé du serveur permettait de retrouver un fonctionnement normal. La cause suspectée : un interblocage (deadlock) entre le service RDP et le Local Session Manager — un phénomène déjà documenté sur le forum Microsoft Q&A avant la sortie du correctif officiel.

Es-tu concerné ?

Le problème touche spécifiquement les serveurs qui exposent le rôle RDS — hôtes de session, connection brokers, passerelles RD Gateway. Si tu utilises Windows Server uniquement pour d’autres rôles (fichiers, contrôleur de domaine, IIS…) sans RDS actif, tu n’es normalement pas impacté par ce bug précis, même si tu as installé les mêmes KB de sécurité. Les postes clients Windows 10/11 ne sont pas directement concernés par le bug RDS serveur, mais ont reçu leurs propres correctifs dans le même lot (voir plus bas).

Le correctif d’urgence est disponible depuis le 14-15 septembre

Microsoft a publié des mises à jour hors bande (out-of-band) pour corriger la régression :

• Windows Server 2019 — KB5129238
• Windows Server 2022 — KB5129237
• Windows Server 2025 — KB5129235

Point important : sur les trois versions serveur, ces correctifs ne sont disponibles que via le Microsoft Update Catalog — pas de déploiement automatique via Windows Update, et pas de distribution native par WSUS sans les importer manuellement. Si tu gères un parc avec WSUS ou Configuration Manager, il faut importer ces KB explicitement.

Au passage, le même lot corrige deux autres bugs introduits par les mises à jour du 8 septembre : le partage de dossiers Linux via Plan9 sous Hyper-V qui devenait inaccessible, et des soucis audio multicanal sur certains périphériques USB Audio Class 1.0.

Comment déployer le correctif

Pour un ou quelques serveurs, le plus rapide est de télécharger le paquet .msu directement depuis le Update Catalog et de l’installer avec DISM :

Add-WindowsPackage -Online -PackagePath "C:\Patches\windows10.0-kb5129235-x64.msu"
Restart-Computer -Force

Pour un parc plus large, importe le KB correspondant à chaque version dans WSUS (Update Services > Actions > Import Updates) ou synchronise-le dans Configuration Manager, puis déploie-le en priorité sur tes hôtes RDS avant les autres serveurs.

Un redémarrage est nécessaire après l’installation pour que le correctif prenne effet — prévois donc une fenêtre de maintenance, surtout si tes hôtes de session hébergent des utilisateurs en horaires décalés.

Si tu ne peux pas patcher tout de suite

Entre la découverte du bug le 8-10 septembre et la sortie du correctif le 14-15, plusieurs administrateurs ont documenté des contournements maison — retrait du paquet fautif via DISM, ou cycle de redémarrage régulier du service Local Session Manager pour éviter le blocage complet. Maintenant que le correctif officiel existe, il n’y a plus de raison de s’appuyer sur ces bricolages : ils ne sont pas documentés par Microsoft et peuvent avoir des effets de bord. Priorise le déploiement du correctif officiel, y compris en dérogeant temporairement à ton cycle de patch management habituel vu la criticité du service concerné.

Éviter que ça se reproduise

Cet épisode est un bon rappel des bonnes pratiques de déploiement de patchs sur des rôles critiques comme RDS :

• Teste les mises à jour de sécurité sur un hôte RDS non critique ou un anneau de déploiement restreint avant de les pousser sur l’ensemble du parc.
• Surveille le tableau de bord Windows Server release health, qui recense les problèmes connus par version et par KB.
• Si tu veux creuser le volet sécurité de ce Patch Tuesday, notre article sur le Patch Tuesday de septembre 2026 détaille les autres failles corrigées ce mois-ci et comment prioriser leur déploiement.

FAQ

Est-ce que ça touche aussi Windows 10 et Windows 11 ?

Le bug RDS en lui-même est spécifique aux rôles serveur. Mais Microsoft a publié le même correctif d’urgence pour les postes clients : KB5129236 pour Windows 10, KB5129195 pour Windows 11 24H2/25H2, et KB5129194 pour Windows 11 26H1. Sur Windows 11 26H1, la mise à jour est bien distribuée via Windows Update classique — contrairement aux versions serveur.

Le correctif passe-t-il par Windows Update automatique sur mes serveurs ?

Non, pour Windows Server 2019, 2022 et 2025, le correctif d’urgence n’est disponible que via le Microsoft Update Catalog. Il faut l’importer manuellement dans WSUS ou ton outil de gestion de patchs.

Faut-il désinstaller la mise à jour du 8 septembre avant d’installer le correctif ?

Non, le correctif d’urgence s’installe par-dessus la mise à jour de sécurité initiale : les correctifs de sécurité du 8 septembre restent appliqués, seule la régression RDS est corrigée.

En résumé

Si tu gères des hôtes RDS sous Windows Server 2019, 2022 ou 2025 et que tu as installé les mises à jour du 8 septembre 2026, vérifie dès maintenant si le correctif d’urgence (KB5129238 / KB5129237 / KB5129235) est déployé sur ton parc. Ce n’est pas un correctif qui arrivera automatiquement par Windows Update : c’est à toi de le récupérer sur le Update Catalog et de le pousser. Si tu veux creuser aussi le volet Active Directory de ce cycle de patchs, notre article sur les changements sécurité d’Active Directory dans Windows Server 2025 complète bien le sujet.

Si tu administres encore des contrôleurs de domaine en 2026, le mois de septembre vient de te donner deux bonnes raisons de t’y intéresser de près : un Patch Tuesday historique qui touche directement Active Directory, et une nouvelle génération de durcissements dans Windows Server 2025 qui change pas mal d’habitudes prises depuis vingt ans. Le grand écart entre « corriger l’urgence » et « préparer la suite » résume bien où en est l’annuaire Microsoft aujourd’hui.

Le Patch Tuesday de septembre 2026, un record qui vise directement tes DC

Microsoft a publié le 8 septembre 2026 le plus gros lot de correctifs de son histoire : 966 failles, dont 105 classées critiques. Deux d’entre elles sont déjà exploitées activement :

• CVE-2026-81963 — élévation de privilèges dans la pile Windows Update, via une résolution de lien incorrecte permettant d’obtenir des droits SYSTEM.
• CVE-2026-85880 — dépassement de tampon dans Windows ALPC, exploitable localement pour élever ses privilèges.

Ce qui doit vraiment retenir ton attention si tu gères un annuaire : 6 CVE touchent Active Directory Domain Services et 4 autres Active Directory Certificate Services, deux composants au cœur de l’authentification et de la gestion des certificats sur tes contrôleurs de domaine. Avec ce volume de correctifs, le tri par criticité et le test en environnement de pré-production ne sont plus optionnels — priorise les CVE AD DS/AD CS avant le reste du lot (détail complet du Patch Tuesday sur BleepingComputer).

Windows Server 2025 : Active Directory fait enfin le ménage

Au-delà du correctif du mois, Windows Server 2025 a apporté à Active Directory sa mise à jour de sécurité la plus dense depuis longtemps. Voici ce qui change concrètement pour toi.

Kerberos : RC4 c’est terminé

Le centre de distribution de clés Kerberos n’émet plus de TGT chiffrés en RC4-HMAC sur un DC Windows Server 2025. Si certaines de tes applications legacy dépendent encore de ce chiffrement (souvent silencieusement, via une bibliothèque ancienne), elles vont commencer à échouer. La clé de registre historique SupportedEncryptionTypes n’est d’ailleurs plus respectée : c’est désormais la stratégie de groupe « Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos » qui fait foi.

LDAP chiffré et signé par défaut

Tous les nouveaux déploiements Active Directory exigent désormais la signature LDAP par défaut, et LDAP passe au chiffrement TLS 1.3 via SCHANNEL. Concrètement : les vieux scripts ou appliances qui font encore du LDAP en clair ou en bind simple non signé vont commencer à générer des échecs de connexion — mieux vaut les identifier avant la mise à niveau que le jour où un utilisateur t’appelle.

Mots de passe de comptes ordinateur générés aléatoirement

Autre changement discret mais important : un DC Windows Server 2025 empêche par défaut de définir le mot de passe d’un compte ordinateur avec le nom du compte lui-même — une pratique historiquement répandue et évidemment risquée. La stratégie de groupe correspondante s’appelle « Contrôleur de domaine : refuser de définir le mot de passe du compte d’ordinateur par défaut ».

Comptes de service managés délégués (dMSA)

Les dMSA offrent enfin un vrai chemin de migration depuis les comptes de service classiques, avec des clés entièrement aléatoires et gérées automatiquement — sans que tu aies à toucher au code des applications qui les utilisent. C’est probablement le changement le plus concret à planifier si tu as encore des comptes de service avec un mot de passe qui n’a pas changé depuis des années.

L’ensemble de ces évolutions est détaillé dans la documentation officielle Microsoft Learn sur les nouveautés de Windows Server 2025, et Microsoft en donne le contexte complet dans cet article Tech Community dédié aux améliorations Active Directory.

Comment préparer ta montée en version sans mauvaise surprise

Avant de basculer tes DC vers Windows Server 2025, quelques vérifications t’évitent une bonne partie des incidents post-migration :

# Repérer les liaisons LDAP non sécurisées sur un DC
# (événements 2887 et 2889 dans le journal Répertoire)
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2887,2889} -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message

# Vérifier le niveau fonctionnel actuel du domaine et de la forêt
Get-ADDomain | Select-Object Name, DomainMode
Get-ADForest | Select-Object Name, ForestMode

# Lister les comptes de service candidats à une migration en dMSA
Get-ADServiceAccount -Filter * -Properties PasswordLastSet |
    Sort-Object PasswordLastSet

Ce type de script s’automatise facilement dans un pipeline de contrôle régulier — si tu veux aller plus loin sur l’automatisation PowerShell de tes tâches d’administration, notre guide complet sur l’automatisation IT avec PowerShell couvre les bases pour industrialiser ce genre de contrôle.

Sur le plan de la conformité, ce durcissement d’Active Directory tombe au bon moment : la directive NIS2 continue sa progression en France et pousse justement vers ce niveau d’exigence sur l’authentification et la gestion des identités. Si ton organisation gère aussi l’accès conditionnel dans Entra ID, notre article sur le changement d’enforcement Conditional Access de juin 2026 complète bien cette mise à jour côté identité hybride.

FAQ

Faut-il migrer tous ses DC vers Windows Server 2025 immédiatement ?

Non — mais il faut au minimum patcher en urgence les vulnérabilités AD DS/AD CS du Patch Tuesday de septembre sur tes DC existants, quelle que soit leur version. La montée vers Windows Server 2025 peut ensuite se planifier sereinement, DC par DC, en commençant par un environnement de test.

Le niveau fonctionnel de forêt 10 est-il obligatoire ?

Non, il n’est requis que si tu veux activer la nouvelle taille de page de base de données 32K. Tu peux exécuter des DC Windows Server 2025 avec un niveau fonctionnel inférieur sans problème.

Comment savoir si des applications utilisent encore RC4 ou du LDAP non signé ?

Active l’audit des événements 2887/2889 (liaisons LDAP non sécurisées) et surveille les échecs d’authentification Kerberos après application des stratégies restreignant RC4, idéalement d’abord en mode audit avant le blocage effectif.

Ce qu’il faut retenir

Entre le Patch Tuesday record de septembre et les durcissements natifs de Windows Server 2025, Active Directory redevient un sujet d’actualité — dans le bon sens du terme. Commence par patcher les CVE AD DS/AD CS sur tes DC actuels, puis planifie ta migration en identifiant en amont les dépendances RC4, LDAP non signé et comptes de service à risque. Ton futur toi t’en remerciera au prochain audit de sécurité.