Volume de CVE Windows en 2026 : ce que les équipes chargées des correctifs doivent mesurer

Sur les trois années complètes de notre nouvelle recherche, le nombre de CVE Windows et Office distinctes est passé de 679 à 941, puis à 2 438 (+38,6 %, puis +159,1 %), tandis que le score de base CVSS v3 moyen passait de 7,43 à 7,37, puis à 7,28. C'est une charge entrante bien plus importante pour une gravité moyenne qui n'a pas augmenté, ce qui explique pourquoi un décompte brut de CVE est une mauvaise façon de piloter un programme de correctifs. Ce billet passe en revue ce que disent les chiffres, comment la cohorte a été constituée, ce qu'il faut mesurer à la place et ce que l'étude n'a pas pu mesurer. La recherche est rédigée par l'entreprise et n'a pas été évaluée par des pairs. Nous l'avons annoncée le 2 novembre, et l'article complet est disponible depuis la page d'inscription.

Ce que disent les chiffres annuels

L'article compare trois années complètes sans chevauchement, chacune allant d'octobre à septembre, afin qu'aucun mois inachevé ne fausse la comparaison.

CVE Windows et Office distinctes dans les trois cohortes annuelles complètes de l'article. Windows et Office se recoupent : l'union est donc dédoublonnée et les deux décomptes ne doivent pas être additionnés.

La hausse n'est pas répartie uniformément. L'article la situe entre le milieu et la fin de 2026 : juillet comptait 483 CVE, août 316 et septembre 819, contre une médiane de 69 par mois sur les 36 mois complets. Octobre 2026 apporte déjà 1 277 CVE Windows et Office jusqu'à la date limite du 26 octobre, dont 1 114 enregistrements du système d'exploitation Windows. Ce sont des totaux mensuels de divulgation révisés, qui incluent des enregistrements hors cycle ; il ne faut donc pas les assimiler à un article de presse qui ne compte que la publication initiale du Patch Tuesday. L'article ne projette pas un seul mois en prévision annuelle et ne revendique ni test de significativité ni point de rupture causal.

Sur les 12 derniers mois de référence (de novembre 2025 à octobre 2026, octobre étant partiel), la cohorte compte 3 565 CVE, soit environ 297,1 par mois de référence. La division par 12 décrit le débit par mois de référence et n'annualise pas octobre. La vérification sur mois complets, jusqu'à septembre 2026, donne 2 438 CVE sur 12 mois, 3 379 sur 24 et 4 058 sur 36.

La gravité moyenne n'a pas augmenté

La moyenne ne permet pas de conclure à une hausse générale de la gravité de base moyenne, mais cela ne signifie pas non plus que le risque a baissé. Le nombre absolu de divulgations graves peut augmenter alors que leur moyenne reste stable : sur la dernière année, 1 841 des 2 436 enregistrements notés (75,6 %) obtiennent au moins 7, et 60 obtiennent 9,0 ou plus. L'article traite le CVSS comme une échelle de gravité et sa moyenne comme un résumé descriptif, pas comme une perte financière attendue ni comme une probabilité de compromission. Les libellés Critical attribués par les éditeurs relèvent d'une autre classification et sont présentés séparément.

L'étude rapproche aussi chaque CVE du catalogue Known Exploited Vulnerabilities de la CISA. L'appartenance à ce catalogue dans les trois cohortes annuelles est de 29, 25 et 21 à la date limite. L'article y voit une coupe transversale descriptive, et non la preuve que l'exploitation devient moins courante : la durée de suivi diffère, la couverture du catalogue est incomplète et un dénominateur en expansion peut abaisser mécaniquement la part observée.

Comment la cohorte a été constituée

La méthode est volontairement prudente, et chaque étape est visible dans l'article.

1. Source. 37 documents CVRF mensuels du Microsoft Security Response Center, d'octobre 2023 à octobre 2026, conservés avec horodatages et empreintes SHA-256.
2. Nettoyage. Sept lignes d'avis non CVE et 48 identifiants CVE explicitement rejetés ont été exclus. Les lignes répétées de versions de produit ont été regroupées en un seul enregistrement par CVE.
3. Périmètre borné. Clients Windows numérotés et produits Windows Server, plus les applications Office de bureau, avec une liste d'autorisation explicite de produits. Les totaux sur l'ensemble des enregistrements du Microsoft Security Response Center ne sont pas la mesure principale, car ils incluent aussi Azure Linux, des services cloud et des composants en amont.
4. Une date par CVE. La date de la première révision valide. L'article précise qu'il s'agit d'un indicateur de divulgation issu des rapports de Microsoft, et non d'une date de découverte observée, d'une date de publication mondiale ou d'une date d'installation de correctif.
5. Un score par CVE. Le score de base CVSS v3.x applicable le plus élevé observé parmi les révisions conservées. Les scores manquants sont exclus de la moyenne et de son dénominateur, et les scores CVSS v4 et temporels ne sont pas mélangés.
6. Rapprochement avec l'exploitation. Appartenance au CISA KEV par identifiant CVE, avec la version 2026.10.23 du catalogue.
7. Mois partiels. Les années complètes vont d'octobre à septembre. Octobre 2026 est présenté à part et n'est jamais traité comme un mois terminé.

Des contrôles automatisés ont confirmé la présence des 37 documents attendus, l'absence de doublons de clés CVE et de périmètre, des plages de scores valides et des décomptes mensuels qui se réconcilient avec les totaux des cohortes. Une comparaison de six enregistrements avec la NVD et l'API CVE Services est un contrôle de cohérence, pas une réplication indépendante, et la NVD n'est pas utilisée comme seul dénominateur des produits notés, car son retard accumulé de 2024 et un changement de politique d'enrichissement en avril 2026 créent une rupture de couverture. Selon l'article, le supplément analytique contient les tables de CVE et de cohortes mensuelles, l'audit du périmètre des produits, les enregistrements exclus et rejetés, les événements de publication des applications et les séries mensuelles, le jeu de données de 17 lignes sur les délais de remédiation et son fichier de couverture, les registres de preuves et un manifeste SHA-256, avec les scripts d'analyse inclus.

Six flux de publication d'applications

Les équipes de packaging ne corrigent pas selon un seul calendrier ; l'article ajoute donc un panel choisi à dessein de six flux de publication : Chrome, Edge, Firefox, Visual Studio Code, Notepad++ et 7-Zip. Un jour de publication est une date distincte à laquelle une version a été publiée pour une application. Sur la dernière année complète, le panel va de 69 jours de publication pour Edge, 64 pour Chrome et 61 pour Visual Studio Code, en passant par 44 pour Firefox et 17 pour Notepad++, jusqu'à 4 pour 7-Zip. Les mois de pointe sont plus chargés que ces moyennes ne le laissent penser : Visual Studio Code a atteint neuf jours de publication en un seul mois.

Sur les 36 mois complets, les six flux ont produit 661 jours de publication propres à une application. Le panel n'est pas un échantillon représentatif des logiciels Windows, les populations de CVE et de publications diffèrent, et l'article précise que les décomptes ne doivent pas être multipliés entre eux ni lus comme une relation de cause à effet. Les jours de publication décrivent la disponibilité et les occasions de surveillance, pas des déploiements obligatoires ni des heures de packaging.

Que mesurer à la place du décompte de CVE

L'article les propose comme des mesures de gestion, et non comme des valeurs déduites des totaux de CVE.

• Délai avant protection vérifiée : de la disponibilité du correctif éditeur applicable à la protection confirmée, y compris les redémarrages de navigateur, les redémarrages de machine et les nouveaux scans. Présentez la médiane et le 90e percentile, ainsi que les installations échouées, le taux de retour arrière et l'expiration des exceptions.
• Délai entre publication et décision, et entre publication et protection pour chaque application et chaque canal.
• Effort de qualification : transitions de version sélectionnées par mois, builds centralisés d'artefacts, et durée de qualification médiane et au 90e percentile.
• Reprises : part des urgences, taux d'échec et de reprise, et arriéré des échecs des programmes de mise à jour.
• Exposition : l'ancienneté des mises à jour de sécurité applicables en attente, ainsi que les instances KEV exposées et leur ancienneté, les actifs non pris en charge et l'arriéré par importance du service.

Sous toutes ces mesures se trouve un inventaire versionné, afin qu'une CVE soit rapprochée des actifs installés et exposés avant que la file de remédiation ne s'allonge. Gardez les décomptes de CVE séparés des instances sur les appareils et de l'effort de déploiement.

Ce que l'étude n'a pas pu mesurer

• Une moyenne de délai de correction sur l'ensemble de la cohorte. Chacune des 4 058 CVE de la fenêtre complète a un horodatage de révision valide, mais aucune date de découverte ou de publication spécifiée. Les 98 265 lignes de remédiation applicables portent toutes la date sentinelle de l'an 0001 avec DateSpecified=false. Des entrées de correctif éditeur existent pour les 4 058 CVE, des entrées de contournement explicites pour cinq et des entrées d'atténuation pour 66, de sorte qu'il n'y a aucun couple de dates structuré exploitable. Des dates manquantes ne sont pas des délais nuls.
• Une horloge unique. Les cas datés, comme trois intervalles de 61, 71 et 81 jours entre le signalement privé et la publication pour PHP et NGINX, utilisent des événements de début et de fin différents et sont présentés séparément, et non regroupés en une moyenne.
• La gravité de chaque CVE de navigateur. Seuls 240 des 2 931 enregistrements liés à Edge (8,2 %) portent un score CVSS v3 numérique applicable dans cette extraction ; la moyenne de ce groupe ne peut donc pas représenter toutes les CVE de navigateur.
• Ce que les administrateurs ont vu le jour même. Les fichiers mensuels historiques sont modifiables et les scores peuvent changer après la divulgation initiale. L'instantané permet de reproduire l'étude, pas de retrouver les états antérieurs des sources.

La place d'EtherApps Forge

L'étude n'évalue ni EtherApps Forge ni aucun produit commercial, et EfficientEther déclare dans l'article son intérêt pour EtherApps Forge. Le lien tient au travail que ces chiffres engendrent. Quand les publications des éditeurs arrivent plus vite, la question du packaging devient : quelles applications empaquetez-vous de façon centralisée, et à quelle vitesse pouvez-vous qualifier chaque nouvelle version ? EtherApps Forge capture les applications Windows là où elles s'exécutent déjà et construit des packages MSIX, MSI, Intune et App Attach signés, ce qui correspond au volet packaging de cette routine. La modernisation et la migration des applications et la modernisation des applications héritées couvrent les applications plus anciennes, les plus difficiles à maintenir à jour, et notre étude précédente sur 3 261 cas d'empaquetage MSIX automatisé montre comment nous séparons la création du package des preuves de lancement et de test.

Obtenez la recherche sur les correctifs Windows pour les tables complètes, la méthode et les mesures que votre équipe peut adopter.