964 CVE en un Patch Tuesday : le modèle du patch management mensuel est structurellement cassé

964 CVE en un seul Patch Tuesday. 104 critiques. 20 failles wormables. Et la même injonction : patcher dans les 72 heures. Je vais vous dire ce que j'observe sur le terrain depuis dix ans : ce modèle est structurellement cassé, et personne ne veut vraiment l'admettre.

964 CVE en un mois : ce que ce chiffre révèle vraiment

Le Patch Tuesday de septembre 2026 est officiellement le plus grand jamais publié par Microsoft. 964 vulnérabilités corrigées en une seule mise à jour mensuelle. Pour replacer ce chiffre dans son contexte : en 2020, un Patch Tuesday typique corrigeait entre 80 et 130 CVE. En 2023, on dépassait régulièrement 200. En 2025, les 400 n'étaient plus rares. Septembre 2026 franchit les 960.

Cette inflation n'est pas un artefact statistique ou un changement de méthode de comptage. Elle reflète trois réalités structurelles. Premièrement, la surface logicielle de Microsoft continue de s'étendre — chaque nouvelle version de Windows, chaque nouveau service cloud, chaque intégration IA ajoute du code et donc des vecteurs d'attaque potentiels. Deuxièmement, les capacités de découverte de vulnérabilités se sont industrialisées : le fuzzing automatisé, les outils de recherche assistés par IA, et la compétition internationale entre chasseurs de primes ont mécaniquement augmenté le taux de découverte. Troisièmement, la pression réglementaire — NIS2, DORA, Cyber Resilience Act — pousse les éditeurs à divulguer plus systématiquement, là où certaines failles auraient été silencieusement patchées dans une mise à jour ordinaire sans CVE dédiée.

Le résultat est une équation impossible pour la plupart des équipes IT : 964 CVE à trier, prioriser, tester et déployer en 30 jours, avant que le prochain Patch Tuesday n'apporte son lot de 800 à 1 000 nouvelles entrées. Dans les grandes organisations avec des centaines de milliers de postes et des milliers de serveurs hétérogènes, le délai médian de patch est encore mesuré en semaines ou en mois pour une fraction significative du parc. Et les attaquants le savent.

Le premier Patch Tuesday à dépasser 500 CVE remonte à 2022. Celui à dépasser 700 à 2024. Nous sommes à 964 en septembre 2026. Si la courbe se maintient — et rien ne laisse penser qu'elle va s'inverser — nous dépasserons le millier dans les douze prochains mois. À quel moment la communauté de sécurité va-t-elle admettre que le modèle du patch mensuel exhaustif est fondamentalement inadapté à ce volume ?

L'illusion du CVSS : pourquoi noter une CVE ne suffit plus

Le réflexe naturel face à 964 CVE est de filtrer par score CVSS. Prioriser le CVSS 10.0, puis le 9.x, puis le 8.x, et traiter le reste selon les ressources disponibles. C'est ce que font la plupart des équipes, faute de mieux. C'est aussi une erreur méthodologique croissante, et les deux zero-days de ce Patch Tuesday en sont une illustration parfaite.

CVE-2026-81963, l'une des deux zero-days exploitées, a un score CVSS de 7.8. Dans une logique de filtrage par seuil, elle passe après les 104 CVE critiques (CVSS >= 9.0). Pourtant, elle était exploitée dans la nature avant la publication du patch. Un attaquant qui a mis un pied dans votre réseau via phishing ou via l'exploitation d'un service exposé va chercher exactement ce type de faille — pas forcément la plus spectaculaire sur le papier, mais exploitable de manière fiable sur des dizaines de versions de Windows, dans le contexte post-intrusion standard.

Le CVSS mesure la sévérité intrinsèque d'une vulnérabilité dans un contexte idéal et normalisé. Il ne mesure pas la probabilité d'exploitation dans votre contexte spécifique. Il ne tient pas compte de la présence d'un PoC public, du fait qu'une CVE est activement scannée par des botnets, ou du fait qu'elle se trouve dans un composant universellement déployé sur l'ensemble de votre parc. Les bases comme CISA KEV apportent une correction partielle en signalant les CVE effectivement exploitées — mais avec un décalage temporel et une couverture incomplète.

En septembre 2026, CISA a ajouté 15 nouvelles CVE à son catalogue KEV dans la même semaine que ce Patch Tuesday. Parmi elles, plusieurs CVE à score CVSS modéré qui, sans ce signal contextuel, auraient été reléguées en bas des listes de priorité. Le CVSS seul, appliqué à 964 CVE, génère une liste de 104 priorités absolues qui est elle-même ingérable pour une équipe de taille normale. Et si votre équipe traite 104 CVE "critiques" avec la même urgence, elle ne traite efficacement aucune d'entre elles.

La domination des EoP : ce que ça révèle sur l'architecture Windows

Près de la moitié des CVE du Patch Tuesday de septembre 2026 sont des vulnérabilités d'élévation de privilèges. Ce n'est pas une anomalie mensuelle — c'est une tendance structurelle dans les Patch Tuesday Microsoft depuis plusieurs années. Elle reflète une réalité architecturale profonde : Windows est un système d'exploitation extrêmement complexe avec des couches d'abstraction accumulées sur trois décennies, et la frontière entre le mode utilisateur et le mode noyau reste une surface d'attaque perpétuellement contestée.

Pour un attaquant, les EoP sont la seconde pièce du puzzle offensif standard. La première pièce est le vecteur d'entrée initial — phishing, exploitation d'un service réseau, credential stuffing. La seconde est l'EoP pour passer de l'exécution en contexte utilisateur standard à SYSTEM ou Domain Admin. Sans EoP, un attaquant qui a compromis un poste de travail via phishing reste bloqué au niveau de l'utilisateur cible, avec des capacités de persistance et de propagation limitées. Avec une EoP fiable, il extrait les credentials en mémoire via LSASS, se propage vers d'autres machines via Pass-the-Hash, et atteint les contrôleurs de domaine.

CVE-2026-85880, la seconde zero-day de ce Patch Tuesday, est un heap buffer overflow dans Windows ALPC (Advanced Local Procedure Call), le mécanisme de communication interprocessus bas niveau qui sous-tend une multitude de services Windows. Il s'agit seulement de la deuxième zero-day exploitée dans ALPC depuis janvier 2023. Les primitives d'exploitation d'ALPC sont particulièrement recherchées car elles sont relativement stables entre versions de Windows — un exploit développé pour Windows 10 a de bonnes chances de fonctionner sur Windows 11 et Windows Server 2022 avec des adaptations mineures. C'est exactement le type d'outil que les groupes APT et les opérateurs ransomware intègrent dans leurs arsenaux et réutilisent sur plusieurs campagnes.

La leçon opérationnelle est contre-intuitive : dans la hiérarchie de priorisation, une faille EoP à CVSS 7.8 dans un composant noyau stable et universellement déployé comme ALPC mérite une attention disproportionnée par rapport à son score. En post-exploitation, elle vaut souvent plus qu'une RCE réseau à CVSS 9.8 dans un composant peu déployé ou accessible uniquement via un protocole spécifique.

Vingt failles wormables : le spectre WannaCry reste réel

En mai 2017, WannaCry s'est propagé dans le monde entier en quelques heures, paralysant des hôpitaux britanniques du NHS, des banques russes, des entreprises industrielles espagnoles et des centaines d'organisations dans plus d'une centaine de pays. Le vecteur était EternalBlue (CVE-2017-0144), une vulnérabilité wormable dans le protocole SMBv1. Microsoft avait publié un patch deux mois avant l'attaque. Des centaines d'organisations n'avaient pas patché — certaines parce qu'elles ne savaient pas qu'elles tournaient sur SMBv1, d'autres parce que le cycle de validation interne prenait trop de temps.

Neuf ans plus tard, le Patch Tuesday de septembre 2026 corrige 20 vulnérabilités wormables simultanément. Une faille wormable est exploitable sans interaction utilisateur, par un attaquant distant, potentiellement propageable de machine en machine de façon autonome — la définition même du vecteur WannaCry. Ces 20 CVE ne sont pas toutes au même niveau de criticité ni dans les mêmes composants réseau. Mais leur présence simultanée dans un même Patch Tuesday représente un risque systémique si le déploiement des correctifs s'étend au-delà de quelques semaines.

La question n'est pas de savoir si quelqu'un va développer un exploit worm pour l'une d'entre elles — c'est une question de quand et pour quelle CVE. En 2026, la capacité à développer un exploit fiable s'est démocratisée. Des agents IA autonomes, comme on l'a vu cette semaine même avec l'affaire PaperCut, peuvent automatiser le développement et le test d'exploits sur des environnements reproduits. Le délai entre patch et exploit fonctionnel, qui était autrefois mesuré en mois pour les vulnérabilités noyau, tend vers quelques semaines pour les vulnérabilités à fort potentiel offensif dans les protocoles réseau Windows.

Les organisations qui maintiennent des parcs Windows avec des délais de patch supérieurs à 30 jours — et elles sont nombreuses dans l'industrie, la santé et les collectivités — jouent avec la possibilité d'un incident wormable. La nouveauté par rapport à 2017 : l'exploitation ne nécessite plus une infrastructure humaine de plusieurs dizaines d'opérateurs pour se propager à grande échelle. Elle peut être entièrement automatisée.

La réalité terrain : ce que font vraiment les équipes IT

Je vais être direct, parce que c'est ce que j'observe dans mes missions depuis dix ans. La grande majorité des équipes IT ne patchent pas en 72 heures. Pas par incompétence — par impossibilité structurelle.

Dans une ETI typique avec 500 serveurs Windows, un Patch Tuesday de 964 CVE génère un travail considérable. D'abord identifier quels systèmes sont concernés (inventaire des versions, des composants actifs, des configurations non standard). Ensuite tester les patches sur un environnement de staging — une exigence non-négociable dans tout secteur où une mise à jour défaillante peut causer une interruption de service (santé, industrie, finance). Puis planifier les fenêtres de maintenance, obtenir les validations métier pour les systèmes critiques, déployer par vagues avec monitoring des régressions, traiter les tickets de régression inévitables. Dans le meilleur des cas, ce cycle prend 10 à 15 jours pour un patch Critique sur les serveurs prioritaires. Pour un patch Important, souvent 30 à 45 jours, parfois plus.

Pendant ce temps, les scanners des attaquants ont identifié les instances vulnérables dans les 24 à 72 heures suivant la publication du Patch Tuesday. Les outils de scan automatisé de CVE nouvellement publiées sont publiquement disponibles et utilisés massivement — par des scripts kiddies, par des groupes cybercriminels, par des acteurs étatiques. La fenêtre d'exploitation nette — entre le début du scan actif et le moment où votre environnement est patché — peut donc s'étirer sur des semaines.

La densité de 964 CVE aggrave le problème d'une autre façon : elle augmente la probabilité de régressions applicatives post-patch. Une mise à jour qui corrige 5 composants peut créer des conflits dans une application métier spécifique. Quand le Patch Tuesday en corrige 964, le risque de collision avec une application interne est mécaniquement plus élevé. Cela pousse les équipes prudentes à étendre leurs fenêtres de test — créant exactement l'exposition prolongée que les attaquants cherchent à exploiter.

RBVM : la seule sortie raisonnable

La réponse à cette impasse n'est pas de patcher plus vite — c'est de patcher mieux. Le Risk-Based Vulnerability Management (RBVM) est une approche qui priorise les vulnérabilités non pas par leur score CVSS intrinsèque mais par leur risque réel dans le contexte spécifique de l'organisation.

Une approche RBVM efficace combine quatre dimensions. L'exploitabilité réelle : la CVE est-elle activement exploitée dans la nature (CISA KEV), existe-t-il un PoC public fonctionnel, des scanners actifs ont-ils été observés ? Une CVE CVSS 7.8 avec PoC public et présence dans CISA KEV est plus urgente qu'une CVE CVSS 9.5 théorique sans exploit connu. L'exposition de l'actif : le système vulnérable est-il exposé sur internet, accessible depuis des zones non fiables, ou isolé dans un réseau interne cloisonné ? Une CVE sur un serveur en DMZ est plus urgente que la même CVE sur un serveur de fichiers en réseau interne. La criticité métier : le système héberge-t-il des données critiques, est-il en Single Point of Failure, est-il dans la chaîne de production ? Les capacités de compensation : dispose-t-on d'un WAF, d'un EDR, d'une segmentation réseau qui réduit l'exploitabilité le temps du patch ?

En combinant ces quatre dimensions, une équipe de cinq personnes peut produire une liste de 15 à 20 CVE absolument prioritaires à partir de 964 entrées — et se concentrer sur celles-ci dans les 48 à 72 heures. Les 940 restantes entrent dans un flux de patch management standard avec des délais adaptés à leur score de risque réel, non à leur score CVSS brut.

Des outils comme Tenable.io avec son Predictive Prioritization, Qualys TruRisk, ou Rapid7 InsightVM avec son Real Risk Score implémentent des variantes de cette approche. Certains s'appuient sur des flux de threat intelligence en temps réel — exploitation observée, PoC publiés, scans actifs détectés — pour ajuster dynamiquement les priorités. L'investissement dans ces outils est généralement rentable dès lors qu'il permet à une équipe limitée de rester dans les délais critiques sans tenter l'impossible.

La dimension humaine est tout aussi importante. Le RBVM n'est pas seulement un outil — c'est un processus qui exige que les équipes IT, sécurité et métier partagent une définition commune des actifs critiques et des niveaux de risque acceptables. Sans cet alignement, les listes de priorité RBVM restent théoriques : l'équipe IT n'a pas l'autorisation de déployer un patch en urgence sur un serveur métier sans validation préalable, même si le RBVM dit que c'est critique. Ce processus de pré-délégation — "dans ces conditions précises, l'équipe IT peut déployer sans validation métier" — est souvent le vrai projet à mener avant même de choisir un outil.

Ce que l'IA change dans cette équation

L'affaire PaperCut de cette semaine — des centaines d'agents IA autonomes exploitant deux CVE dans 395 organisations simultanément — n'est pas un cas isolé. C'est le signal précurseur d'une transformation structurelle du côté offensif.

Jusqu'à présent, l'exploitation à grande échelle nécessitait des ressources humaines importantes : des équipes d'opérateurs maintenant les accès, adaptant les exploits aux configurations cibles, gérant les compromissions. Cette contrainte bridait naturellement le volume d'attaques simultanées. Avec des agents IA capables de reproduire la logique de reconnaissance, d'adaptation d'exploit et de post-exploitation, cette contrainte s'effondre. Le coût marginal d'une compromission supplémentaire tend vers zéro du côté de l'attaquant.

Ce déséquilibre croissant entre la vitesse d'exploitation côté attaquant et la vitesse de patch côté défenseur ne peut pas être compensé par plus d'effort humain. Il exige une réponse systémique : automatisation de la priorisation, pré-autorisation des déploiements d'urgence, et capacité de détection post-exploitation pour les cas où le patch n'arrive pas à temps.

Conclusion

964 CVE en un Patch Tuesday. Ce chiffre ne va pas diminuer. L'année prochaine, il sera probablement plus élevé. La complexité logicielle de Windows continue de croître, les outils de découverte s'améliorent, et la pression réglementaire pousse à une divulgation toujours plus exhaustive. Les organisations qui n'adaptent pas leurs processus de gestion des vulnérabilités à cette réalité accumulent une dette que les attaquants — humains ou IA — seront prêts à exploiter.

La bonne nouvelle : la solution n'est pas de patcher 964 CVE en 72 heures. C'est de patcher les 15 à 20 qui comptent vraiment en 72 heures, et de construire un processus structuré et pré-autorisé pour le reste. C'est faisable, mais ça exige un changement de méthode — pas juste plus d'effort de la même équipe sur le même processus.