Le 14 octobre 2026, Microsoft a publié son Patch Tuesday mensuel. Le chiffre est inédit : 1 413 vulnérabilités corrigées en un seul cycle. C'est le volume le plus élevé jamais enregistré pour un Patch Tuesday, selon les décomptes de SecurityWeek et BleepingComputer publiés le 13 octobre 2026. Parmi ces correctifs, deux failles avaient déjà été divulguées publiquement avant leur correction. L'une d'elles, CVE-2026-96951, affecte une fonction de sécurité Windows et était activement exploitée en production avant la publication du correctif.
Ce chiffre ne surgit pas dans le vide. Il s'inscrit dans un mouvement de fond : depuis le début de 2026, le rythme des divulgations de vulnérabilités s'accélère, et le délai entre la publication d'un correctif et son exploitation active raccourcit.
Quand la fenêtre d'exploitation se réduit à quelques heures
La même semaine, la CISA a confirmé qu'une faille critique dans le plugin WordPress Bricksforge, notée CVSS 10.0, était activement exploitée. Cette faille permet à un attaquant non authentifié d'exécuter du code à distance sur tout site WordPress utilisant une version non corrigée. Les premières tentatives d'exploitation ont été détectées quelques heures après la publication de l'avis de sécurité.
À cela s'ajoutent d'autres avis publiés entre le 8 et le 13 octobre : une faille critique dans SonicWall SMA 1000, une vulnérabilité de sévérité maximale dans GitLab CI/CD permettant une exécution de code à distance, et un contournement d'authentification dans Fortinet FortiSandbox. Chacun de ces produits est présent dans des infrastructures d'organisations soumises à NIS2 ou DORA.
Ce que la réglementation impose : 24 heures, pas trois semaines
Le Cyber Resilience Act (CRA), applicable dans ses obligations de signalement depuis le 11 septembre 2026, impose aux fabricants de produits numériques de notifier l'ENISA et le CSIRT national compétent dans les 24 heures suivant la découverte d'une vulnérabilité activement exploitée. La notification complète doit parvenir dans les 72 heures suivantes.
NIS2 s'applique de son côté aux entités essentielles et importantes. En cas d'incident significatif lié à une vulnérabilité exploitée, l'article 23 de la directive impose une alerte précoce dans les 24 heures. Ces délais supposent que l'organisation sache, en temps réel, quels composants logiciels elle utilise et dans quelles versions.
C'est là que le problème se pose concrètement : si votre inventaire logiciel n'est pas à jour, vous ne saurez pas que CVE-2026-96951 affecte vos postes Windows avant que vos équipes l'aient lu dans la presse. Le délai de 24 heures devient alors intenable. Notre article sur le SBOM et l'inventaire logiciel sous NIS2 et DORA détaille pourquoi la connaissance de votre parc logiciel est le préalable incontournable à toute politique de correctifs réglementairement solide.
Un exemple concret : le plugin WordPress exploité dès le premier jour
Prenons le cas de Bricksforge. Ce plugin est utilisé par des agences web pour construire des interfaces visuelles sur WordPress. Ses utilisateurs ne sont pas des professionnels de la sécurité : ce sont des équipes marketing, des PME, des collectivités. Quand la faille est divulguée avec un CVSS de 10.0, la question n'est pas de savoir s'il faut corriger, mais de savoir si l'organisation dispose d'un mécanisme automatique pour détecter la présence de ce plugin dans son parc et déclencher la mise à jour avant que les premières tentatives d'exploitation n'atteignent son infrastructure.
Sans inventaire automatisé des composants installés sur les sites que vous gérez ou hébergez, cette question reste sans réponse pendant des jours. Pendant ce temps, les scanners des attaquants, eux, n'attendent pas.
Si vous confiez la maintenance de vos sites web à un prestataire, vérifiez que le contrat de maintenance inclut explicitement la surveillance des mises à jour de sécurité et le déploiement des correctifs critiques sous un délai défini contractuellement.
Le patch management manuel ne peut plus fonctionner à ce volume
Un Patch Tuesday qui dépasse 1 400 CVE signifie que les équipes sécurité doivent trier, qualifier et décider en quelques jours du niveau de priorité de chaque correctif. À ce volume, un processus entièrement manuel génère des retards inévitables. Certains correctifs critiques attendront des semaines parce qu'ils auront été submergés par le flux.
Les approches opérationnellement viables combinent plusieurs mécanismes.
- Un inventaire logiciel maintenu en temps réel (SBOM ou équivalent), qui lie chaque CVE aux composants effectivement présents dans votre parc.
- Un score de priorité qui tient compte du CVSS, mais aussi de l'exploitation active confirmée dans le catalogue KEV de la CISA et de la présence réelle du composant dans votre environnement.
- Des circuits d'approbation différenciés : un correctif critique sur un composant exposé à Internet ne doit pas suivre le même cycle de validation qu'une mise à jour fonctionnelle.
- Des tests de non-régression automatisés pour les correctifs à déploiement rapide, afin de ne pas échanger une vulnérabilité contre une panne de service.
Ce que le volume de CVE révèle sur la dette technique
Le chiffre de 1 413 CVE en un mois reflète l'état du parc logiciel mondial : les équipes de recherche trouvent davantage de vulnérabilités, les éditeurs en corrigent davantage, et les attaquants investissent dans la détection des fenêtres d'exploitation entre la divulgation et le déploiement du correctif.
Pour les organisations soumises à NIS2, ce volume soulève une question documentaire directe. Êtes-vous en mesure de produire, en cas d'audit ou d'incident, la preuve que vous avez traité chaque CVE applicable à votre périmètre dans un délai raisonnable ? Un journal de correctifs complété manuellement et sporadiquement ne constituera pas une preuve satisfaisante face à une autorité nationale compétente.
Le renforcement de la posture de correctifs ne se limite pas à un outil. Il suppose une décision organisationnelle : qui est responsable de l'inventaire, qui décide de la priorisation, et quel délai maximum est acceptable pour chaque niveau de criticité. Ces trois éléments doivent figurer dans votre politique de sécurité formelle, exigée par l'article 21 de NIS2.
Pour aller plus loin sur la mise en place d'une gestion structurée des vulnérabilités, notre prestation d'intégration des outils de sécurité couvre la sélection et le déploiement des mécanismes adaptés à votre environnement et à vos obligations réglementaires.