La mise à jour devait fermer la porte
Le Patch Tuesday de Microsoft de septembre 2026 a inclus un correctif pour CVE-2026-69525, une faille des Services Bureau à distance notée 9.8 sur 10 sur l'échelle CVSS, le genre de score réservé aux failles qu'un inconnu sur internet peut exploiter sans mot de passe. Un paquet spécialement conçu envoyé sur le port 3389 pouvait déclencher une erreur use-after-free et exécuter du code avec les privilèges du service, sans connexion requise.
Les administrateurs ayant appliqué la mise à jour dans les délais, le choix responsable selon tout critère normal, ont fait exactement ce que les équipes de sécurité demandent chaque mois.
Puis le Bureau à distance a commencé à tomber tout seul
Quelques heures après l'installation de KB5122876 sur Server 2019, KB5122882 sur Server 2022 ou KB5122871 sur Server 2025, les Services Bureau à distance ont commencé à défaillir. Des connexions qui fonctionnaient au démarrage cessaient de fonctionner quelques heures plus tard. Les sessions existantes ne pouvaient pas se déconnecter proprement. Les nouvelles tentatives de connexion restaient bloquées puis finissaient par expirer, et dans les pires cas, seul un redémarrage forcé du serveur permettait de corriger le problème.
Un administrateur a décrit le schéma sans détour: ça fonctionne au début, mais après la première déconnexion, le service plante et plus aucun utilisateur ne peut se connecter. Un chercheur ayant retracé la faille a pointé un blocage mutuel entre le processus du Bureau à distance et le Local Session Manager, un diagnostic que Microsoft n'a pas confirmé.
Ce qui a cassé, et où
| Version de Windows Server | Mise à jour | Symptôme |
|---|---|---|
| Server 2019 | KB5122876 | RDS tombe en panne des heures après le démarrage |
| Server 2022 | KB5122882 | Les sessions se bloquent à la déconnexion |
| Server 2025 | KB5122871 | Les nouvelles connexions expirent |
Microsoft a seulement confirmé avoir connaissance des signalements et enquêter. L'entreprise n'a confirmé ni la cause profonde ni de date pour un correctif.
Pourquoi c'est important
Pourquoi c'est important: Ce n'est pas un débat abstrait sur la gestion des correctifs, c'est un choix bien réel pour toute équipe qui exploite Windows Server avec un Bureau à distance exposé, ce qui, dans les opérations européennes et britanniques avec du personnel à distance, des prestataires ou des agences, concerne la plupart d'entre elles. Revenir en arrière rouvre sur les mêmes serveurs une faille de gravité 9.8 exploitable sans identifiants. La laisser installée peut faire cesser de fonctionner sans prévenir l'accès distant lui-même, la raison d'être de ces serveurs.
Oui, mais
Oui, mais: Aucune des deux options n'est en réalité la seule issue. Les administrateurs qui ne peuvent risquer ni un retour en arrière complet ni un accès distant cassé restreignent plutôt l'exposition RDP au niveau réseau, en limitant le port 3389 à un VPN ou un jump host plutôt qu'à l'internet ouvert, ce qui garde le correctif installé, ferme la voie la plus facile vers la vulnérabilité corrigée, et laisse le temps à un correctif officiel sans parier sur l'un ou l'autre scénario d'échec.
L'essentiel à retenir
L'essentiel à retenir: "Tout corriger immédiatement" et "attendre une semaine par sécurité" sont tous deux le mauvais réflexe ici, car la véritable décision ne porte pas sur la vitesse, mais sur l'exposition. Testez chaque mise à jour cumulative sur un petit groupe canari avant qu'elle n'atteigne tous les serveurs, et restreignez l'accès réseau à tout ce que la mise à jour pourrait toucher, pour qu'un correctif défaillant dégrade une poignée de machines plutôt que toutes les sessions Bureau à distance de l'entreprise à la fois.
À lire ensuite: Le choc du PDG d'Apple en 2011 a coûté 12 fois plus qu'en 2026 | Le virage de Xbox portait sur le marketing, pas les jeux
