Logiciels & outils pro

Faille critique WSUS CVE-2025-59287 : serveurs touchés et correctif

10 novembre 2026 Nathalie Blanc 7 min de lecture

La faille critique WSUS CVE-2025-59287 permet à un attaquant d’exécuter du code à distance sur un serveur Windows dont le rôle WSUS est actif. Son score CVSS atteint 9,8 sur 10 et des attaques ont été observées. Si vous exploitez WSUS, identifiez vos serveurs, appliquez la mise à jour adaptée et limitez leur accès réseau sans attendre.

La vulnérabilité concerne plusieurs générations de Windows Server, de 2012 à 2025. Un correctif publié le 14 octobre 2025 a été jugé insuffisant : une mise à jour hors bande a ensuite été proposée. Un serveur qui ne fait pas fonctionner le rôle WSUS n’est pas exposé à cette faille par ce composant.

Table des matières

Pourquoi cette faille WSUS est-elle critique ?

WSUS, pour Windows Server Update Services, sert à distribuer les mises à jour Microsoft aux machines d’un réseau. Il occupe donc une place sensible : les postes et les serveurs doivent pouvoir communiquer avec lui pour recevoir leurs mises à jour.

Schéma du fonctionnement de la faille critique WSUS, de la requête réseau aux conséquences possibles

CVE-2025-59287 est une faille d’exécution de code à distance. L’exploitation décrite ne nécessite pas d’authentification et peut donner à l’attaquant des privilèges SYSTEM sur le serveur. Ce niveau de droits lui permet notamment de lancer des commandes et de chercher à atteindre d’autres systèmes accessibles depuis la machine compromise.

L’urgence dépend aussi de l’accès au service : un WSUS non corrigé accessible depuis Internet est une priorité absolue. Un serveur limité au réseau interne reste néanmoins exposé à un attaquant déjà présent sur ce réseau.

Quels serveurs Windows sont concernés ?

Le rôle WSUS doit être actif pour que le serveur soit exposé à cette vulnérabilité par ce service. WSUS n’est pas activé par défaut. Les installations Server Core figurent aussi parmi les configurations concernées pour plusieurs versions : l’absence d’interface graphique ne constitue pas une protection.

Les dernières mises à jour et alertes officielles de Windows : Consultez les annonces Microsoft, avis de sécurité et références des mises à jour de Windows 11.

Le tableau donne, par système, la version corrigée : une version antérieure à ce seuil est affectée lorsque WSUS est actif.

Système	Version corrigée indiquée
Windows Server 2012	6.2.9200.25728
Windows Server 2012 R2	6.3.9600.22826
Windows Server 2016	10.0.14393.8524
Windows Server 2019	10.0.17763.7922
Windows Server 2022	10.0.20348.4297
Windows Server 2022, édition 23H2, Server Core	10.0.25398.1916
Windows Server 2025	10.0.26100.6905

Comment savoir si votre serveur est exposé ?

Identifiez le système et sa version. La commande winver affiche les informations de version de Windows. Comparez-les au seuil correspondant dans le tableau.
Recherchez le rôle WSUS. Dans PowerShell, la commande Get-WindowsFeature -Name UpdateServices* permet de voir les composants WSUS installés ; la colonne d’état indique si le rôle est installé.
Repérez les accès réseau. Examinez les règles de pare-feu, les publications et les ports d’écoute du serveur. Les ports habituels sont 8530 et 8531 en TCP ; certaines installations utilisent aussi 80 ou 443.
Déterminez qui peut joindre le service. Distinguez l’accès depuis Internet, depuis les réseaux internes et depuis les seuls postes ou serveurs autorisés à utiliser WSUS.

Un serveur vulnérable possède la version et le rôle concernés. Il est exposé si un attaquant peut atteindre le service. Il n’est pas forcément compromis pour autant : seule une investigation peut établir si une exploitation a eu lieu.

Comment fonctionne l’exploitation ?

La faille se situe dans le traitement de données reçues par un service Web de WSUS. Le composant ClientWebService, et notamment le point d’accès SyncUpdates, traite des requêtes échangées avec les clients. Une requête SOAP spécialement conçue peut atteindre le traitement de l’objet AuthorizationCookie.

Le problème tient à une désérialisation non sécurisée. Pour faire simple, le serveur transforme des données reçues en objet utilisable par son programme. Si ce traitement accepte des données malveillantes, il peut déclencher du code au lieu de se limiter à lire les informations attendues. Le mécanisme décrit implique le composant .NET BinaryFormatter.

Le nom AuthorizationCookie ne signifie pas que l’attaquant doit posséder un compte valide : l’exploitation rapportée est non authentifiée. La condition pratique reste l’accès réseau au service vulnérable.

Des attaques ont-elles déjà eu lieu ?

Oui. Des attaques ont été rapportées à partir du 23 octobre 2025 à 23 h 34 UTC. Après l’exploitation, les activités observées comprennent l’exécution de commandes, la reconnaissance du système et du réseau, ainsi que le téléchargement de charges utiles.

Des communications vers l’extérieur, des activités d’exfiltration et une installation possible de mécanismes de persistance ont également été rapportées. Ces comportements ne se produisent pas nécessairement dans chaque incident. Leur absence dans un journal isolé ne suffit donc pas à exclure une compromission.

Quel correctif installer pour CVE-2025-59287 ?

Appliquez la mise à jour de sécurité hors bande correspondant à votre version et à votre édition de Windows Server, ou une mise à jour ultérieure qui l’intègre. Le correctif initial du 14 octobre 2025 ne doit pas être considéré, à lui seul, comme une protection suffisante : il a été suivi d’une correction supplémentaire. Concrètement, un serveur qui n’a reçu que ce premier correctif peut rester exploitable.

Ne vous arrêtez donc pas à la présence de la mise à jour initiale : contrôlez que la version effectivement installée atteint au moins celle du tableau pour votre système.

Recensez tous les serveurs qui exécutent WSUS, y compris les serveurs secondaires et les installations Server Core.
Relevez leur version, leur édition et leur niveau de mise à jour.
Déployez le correctif adapté, puis redémarrez le serveur si l’installation le demande.
Contrôlez le résultat de l’installation et la version obtenue. Assurez-vous ensuite que les clients autorisés peuvent de nouveau joindre WSUS.
Conservez une surveillance après la correction : installer un correctif ferme la faille, mais ne supprime pas nécessairement un accès déjà installé par un attaquant.

Que faire si la mise à jour ne peut pas être immédiate ?

Les mesures temporaires réduisent l’exposition, mais ne remplacent pas le correctif.

Situation	Action temporaire	Conséquence
WSUS accessible depuis Internet	Couper en priorité l’accès public au service, puis appliquer le correctif.	Les clients externes ne peuvent plus le joindre par ce chemin.
Service utilisable uniquement en interne	Restreindre les flux entrants aux machines et réseaux qui ont besoin de WSUS.	Les clients exclus ne reçoivent plus les mises à jour par ce serveur.
Isolation nécessaire ou service non indispensable immédiatement	Bloquer le trafic entrant vers WSUS ou désactiver son rôle.	La distribution via ce serveur est interrompue.

Adaptez les règles aux ports réellement utilisés : 8530/TCP et 8531/TCP sont courants, mais 80 et 443 peuvent aussi servir. Bloquer seulement les ports habituels ne protège pas une instance configurée ailleurs. À l’inverse, bloquer 80 ou 443 sur un serveur partagé peut interrompre d’autres services Web.

Avant une coupure prolongée, recensez les machines qui dépendent de ce WSUS et leur moyen temporaire d’obtenir les mises à jour. Après correction, rétablissez uniquement les flux nécessaires et confirmez que les clients reprennent leurs communications.

Quels signes d’exploitation rechercher ?

Examinez les journaux du serveur Web, les événements de sécurité, les alertes de votre outil de protection et les connexions sortantes autour de la période d’exposition. Cherchez en particulier :

des requêtes inhabituelles vers les services Web WSUS, notamment autour de ClientWebService et SyncUpdates ;
des connexions inhabituelles vers les ports 8530 et 8531, ou vers 80 et 443 selon la configuration du serveur ;
le lancement suspect de cmd.exe ou de PowerShell en lien avec les processus serveur w3wp.exe ou wsusservice.exe ;
l’utilisation inattendue de curl ou de msiexec, notamment avec des téléchargements ou des installations non prévus ;
des commandes de reconnaissance, des connexions externes inhabituelles ou de nouveaux mécanismes de persistance.

Ces éléments sont des pistes d’enquête, pas des preuves automatiques : certains processus et outils ont aussi des usages légitimes. Rapprochez l’heure, le compte utilisé, la ligne de commande, le processus parent et la destination réseau avant de conclure.

Si plusieurs indices concordent, isolez le serveur selon votre procédure d’incident, conservez les journaux et autres éléments utiles, puis recherchez les actions menées depuis cette machine. Traitez le correctif et l’investigation comme deux tâches distinctes : un serveur désormais à jour peut avoir été compromis avant son redémarrage.