KB5083769 casse les sauvegardes VSS sous Windows 11

Ce qui s'est passé

Microsoft a publié le 14 avril 2026 le bulletin KB5083769, un cumulative update de sécurité couvrant les builds 26200.8246 (Windows 11 25H2) et 26100.8246 (Windows 11 24H2). Ce correctif corrige plus de 130 vulnérabilités dont une dizaine cotées Critique, et introduit le durcissement de la pile cryptographique post-quantique sur les composants Schannel et BCrypt. Mais à partir du 17 avril, plusieurs éditeurs de solutions de sauvegarde ont commencé à signaler des dysfonctionnements en série sur les machines mises à jour.

Le mécanisme défaillant est le Volume Shadow Copy Service, ou VSS, brique fondamentale de l'écosystème de sauvegarde Windows depuis Server 2003. VSS coordonne les writers applicatifs (SQL Server, Exchange, Hyper-V) et les providers de stockage pour produire des snapshots cohérents qui servent de point de départ aux backups. Avec KB5083769, le service VSS expose un nouveau délai de timeout interne lors du flush des writers, et ce timeout n'est pas exposé via les API publiques. Résultat : les requêtes VssCreateSnapshot émises par les agents de sauvegarde tiers échouent silencieusement avec un code retour SUCCESS, alors que le snapshot sous-jacent est incomplet ou corrompu.

Acronis a été le premier à publier un avis de sécurité, le 21 avril, listant Acronis Cyber Protect Cloud et Cyber Protect 16 comme impactés sur tous les serveurs Windows mis à jour. Macrium a suivi le 23 avril avec un avis similaire pour Reflect Server 8 et Reflect Workstation 8. NinjaOne a confirmé le 25 avril l'impact sur ses agents de sauvegarde managée, et UrBackup a publié un correctif partiel via une mise à jour de son provider VSS le 28 avril. Les éditeurs sont unanimes : la cause racine est externe à leurs produits et relève de KB5083769.

La criticité du bug réside dans son caractère silencieux. Les administrateurs voient leurs jobs de sauvegarde se terminer avec un statut « réussi » dans les consoles d'orchestration. Les rapports quotidiens envoyés au RSSI affichent un taux de succès de 100 %. Ce n'est qu'à la première tentative de restauration que le problème se révèle : le snapshot ne contient qu'une partie des fichiers, ou les bases SQL Server retournent des erreurs de cohérence DBCC CHECKDB. Plusieurs cas documentés sur Reddit et sur le forum AskWoody font état de pertes de données réelles dans des PME qui ont tenté de restaurer après un sinistre disque survenu fin avril.

Microsoft n'a pas, à la date du 30 avril, ajouté ce bug au champ « Known Issues » du bulletin KB5083769. La firme a en revanche reconnu informellement le problème via plusieurs réponses sur ses forums Microsoft Q&A, et confirme un correctif ciblé attendu dans le cumulative update de mai 2026 ou via un release out-of-band si la pression industrielle augmente. AskWoody a relevé son indice MS-DEFCON à 3, recommandant le report immédiat de l'application de KB5083769.

Le bug ne touche que Windows 11 24H2 et 25H2 ; les builds 23H2 et antérieures ne sont pas concernées, de même que les serveurs Windows Server 2022 et 2025 qui reçoivent un cumulative update distinct (KB5083631) avec une régression VSS différente, également signalée par Macrium. La symétrie suggère un problème d'architecture commun aux deux trains de mise à jour, vraisemblablement lié à la refonte du composant Coordinated Pause introduite dans la branche servicing 2026 de Windows.

Côté workaround, les éditeurs convergent sur un protocole en cinq étapes. D'abord, désinstaller manuellement KB5083769 via Paramètres > Windows Update > Historique des mises à jour > Désinstaller des mises à jour. Ensuite, mettre Windows Update en pause pour 35 jours. Troisièmement, redémarrer le poste pour réinitialiser proprement les writers VSS. Quatrièmement, déclencher un job de sauvegarde test et vérifier intégrité du snapshot via vssadmin list shadows et vssadmin list writers. Enfin, et c'est le point critique, exécuter une restauration test sur un environnement bac à sable : la seule façon fiable de confirmer que le bug est neutralisé.

Pour les flottes managées, Acronis et NinjaOne ont publié des scripts PowerShell de remédiation en bulk via leurs consoles cloud. Microsoft Endpoint Manager (Intune) propose désormais un script de désinstallation conditionnelle basé sur la présence du KB. Les organisations qui pilotent leurs mises à jour via WSUS doivent décliner explicitement KB5083769 dans leur plan d'approbation pour éviter sa réinstallation automatique.

Pourquoi c'est important

L'incident illustre une faiblesse structurelle des stratégies de sauvegarde modernes : la confiance dans le statut renvoyé par l'API VSS. Pendant deux décennies, la communauté infrastructure a construit ses processus DR sur l'hypothèse que VSS retournait soit un succès, soit une erreur explicite. KB5083769 démontre que cette hypothèse peut être violée par un simple changement de timeout dans un cumulative update, et que les conséquences peuvent rester invisibles pendant des semaines, jusqu'à ce que la première restauration révèle le désastre.

Pour les RSSI et les responsables continuité, la leçon est connue mais rarement appliquée à la lettre : un backup non testé n'est pas un backup. Les politiques DR doivent imposer des tests de restauration périodiques, idéalement mensuels pour les systèmes Tier 1, et inclure un volet de validation cryptographique des contenus restaurés. Les frameworks NIST SP 800-34 et ISO 22301 prévoient ce contrôle, mais les audits sécurité montrent qu'il est l'un des plus régulièrement négligés. KB5083769 va sans doute provoquer une vague d'incidents DR dans les semaines à venir, dans toutes les organisations qui n'appliquent pas ce contrôle.

L'affaire pose aussi une question de gouvernance vis-à-vis de Microsoft. La politique de mise à jour Windows-as-a-Service rend obligatoire l'application des cumulative updates pour rester en support, et l'opt-out granulaire est techniquement complexe. Or, les régressions silencieuses comme celle de VSS ne sont pas des cas isolés : Windows 10 22H2 a connu en 2024 une régression équivalente sur Hyper-V backup, et Windows Server 2019 en 2023 sur les snapshots ReFS. La fréquence de ces incidents devrait inciter les organisations à imposer un délai de quarantaine systématique entre publication d'un cumulative update et déploiement en production, idéalement de 14 jours sur un échantillon représentatif.

Enfin, l'épisode renforce la pertinence des stratégies de sauvegarde immutables et déconnectées du runtime Windows. Les solutions s'appuyant sur des snapshots côté stockage (NetApp SnapCenter, Pure Storage SafeMode, Dell PowerProtect) ou sur du ZFS ne sont pas affectées par KB5083769, puisqu'elles ne reposent pas sur VSS. Les architectures qui combinent un backup local Windows-VSS et un backup objet S3 immutable côté cloud (avec object lock) bénéficient d'une redondance qui couvre précisément ce type de régression. Les RSSI qui pilotent leur transformation backup en 2026 ont là un argument de plus pour basculer vers des architectures sans VSS sur les workloads critiques.

Ce qu'il faut retenir

• KB5083769 brise silencieusement VSS sur Windows 11 24H2/25H2 ; les sauvegardes terminent en succès mais sont corrompues.
• Désinstaller le KB, mettre Windows Update en pause, et surtout exécuter un test de restauration : un backup non testé n'est pas un backup.
• L'incident plaide pour des architectures backup multi-couches qui ne dépendent pas exclusivement de VSS.