Patch Tuesday : 28% des CVE exploités en moins de 24h

Le rapport M-Trends 2026 publié par Mandiant met un chiffre sur ce qu'on sentait depuis deux ans : 28,3 pour cent des CVE publiées en 2025 ont été exploitées dans les 24 heures suivant leur disclosure. Le Patch Tuesday mensuel hérité des années 2000 ne tient plus la route. Il faut revoir entièrement le pipeline de remédiation.

Le chiffre qui change tout

Rappelons rapidement ce qu'est le Patch Tuesday : Microsoft a institué en 2003 le second mardi de chaque mois comme rendez-vous unique pour publier les correctifs Windows et Office. L'idée tenait debout à l'époque : fenêtre prévisible, cycle de validation interne d'un mois côté entreprise, communication groupée. Vingt ans plus tard, l'industrie entière fonctionne encore sur ce rythme : Adobe, Oracle, SAP, et même la majorité des éditeurs Linux d'entreprise alignent leurs releases sur cette cadence ou sur des cycles trimestriels.

Le problème : les attaquants, eux, n'ont jamais signé ce contrat tacite. Mandiant relève dans M-Trends 2026 que 28,3 pour cent des CVE publiées en 2025 ont vu une tentative d'exploitation dans les 24 heures suivant leur disclosure publique. Ce chiffre était à 12 pour cent en 2022, et à 4 pour cent en 2018. La courbe est exponentielle et le facteur d'accélération est connu : automatisation poussée du fingerprinting Internet par les frameworks comme Shodan, Censys et Cybertan, mais surtout entraînement de modèles d'IA spécialisés sur la lecture des advisories pour générer du code d'exploitation en quelques minutes.

Concrètement, sur 100 CVE publiées un lundi soir, environ 28 sont exploitées avant le mardi midi. Si vous attendez le Patch Tuesday du mois suivant pour patcher, vous laissez aux attaquants une fenêtre de quatre à six semaines sur des vulnérabilités déjà armées. Ce délai était acceptable quand l'exploitation prenait six mois en moyenne. Il ne l'est plus quand elle prend six heures.

Pourquoi le Patch Tuesday tient encore

Si la pratique est dépassée, pourquoi persiste-t-elle ? Trois raisons opérationnelles solides :

D'abord, le coût de la régression. Patcher en flux continu signifie déployer des correctifs sans la batterie de tests de non-régression que les équipes Ops ont l'habitude de mener. Sur des SI complexes — ERP SAP, applications métier maison, systèmes embarqués industriels — un patch mal testé peut casser une chaîne logistique, une production ou un service client critique. Le coût d'indisponibilité dépasse souvent le coût d'un éventuel breach. C'est un calcul froid mais rationnel.

Ensuite, l'économie d'échelle organisationnelle. Patcher 5 000 serveurs et 30 000 postes de travail mobilise des équipes entières pendant plusieurs jours. Faire ce travail mensuellement permet de planifier, de prévoir les reboots, de coordonner avec les métiers. Le faire en flux continu suppose une transformation profonde des processus et de l'outillage que la plupart des DSI françaises n'ont pas finalisée — sauf peut-être chez les grands acteurs cloud-natifs.

Enfin, le confort psychologique. Un cycle mensuel produit une illusion de contrôle. On signe un PV de patch, on coche une case d'audit, on rapporte un KPI. La réalité — que les vulnérabilités les plus critiques sont exploitées avant même que le PV ne soit signé — est inconfortable et préfère être ignorée tant qu'aucun incident ne force la remise en question.

Ce qui marche en 2026

Plusieurs approches émergent pour sortir du piège. Aucune n'est nouvelle, mais elles deviennent obligatoires plutôt qu'optionnelles.

La première est la segmentation par criticité avec deux pipelines distincts. Les CVE avec CVSS supérieur à 8 et exploitation active confirmée — par CISA KEV ou par les feeds threat intelligence — passent en pipeline express avec déploiement en moins de 72 heures, après tests de non-régression réduits sur un environnement représentatif. Le reste suit le cycle mensuel classique. Cette dichotomie suppose une gouvernance claire et un budget dédié à la cellule patch d'urgence, mais elle est devenue indispensable.

La deuxième est la compensation par mitigation temporaire. Quand le patch n'est pas immédiatement déployable — typiquement sur un système de production industriel — le contournement par règles WAF, segmentation réseau ou désactivation du module vulnérable doit être appliqué dans les heures qui suivent l'alerte. Cela suppose une cartographie à jour des dépendances et une équipe SOC capable de pousser des règles défensives sans attendre le cycle de patch. La désactivation préventive du module algif_aead pour la faille Linux Copy Fail en mai 2026 est un exemple type : le module est rarement utilisé, le bloquer coûte rien, et neutralise complètement la faille.

La troisième est l'automatisation du déploiement avec rollback rapide. Plutôt que de tester pendant trois semaines avant de déployer, on déploie sur une fraction du parc — disons 10 pour cent — avec monitoring serré et capacité de rollback en moins d'une heure si une régression est détectée. C'est le principe du canary deployment appliqué au patching. Sur Windows, les outils comme Microsoft Intune et Endpoint Configuration Manager permettent ce mode opératoire depuis plusieurs années, mais peu d'organisations l'utilisent réellement par crainte du risque.

Le rôle des feeds threat intelligence

Pour prioriser correctement, il faut savoir lesquelles des 1 500 CVE publiées chaque mois sont activement exploitées. Le KEV catalog de la CISA est devenu la référence de fait : 1 200 CVE listées au 9 mai 2026, avec dates d'ajout, deadlines fédérales et notes d'exploitation. Tout outil de gestion de vulnérabilités (Tenable, Qualys, Rapid7) intègre désormais ce flux et permet de filtrer les findings sur ce critère.

Au-delà de KEV, les feeds commerciaux comme Mandiant Intelligence, Recorded Future ou Sekoia.io apportent un signal plus précoce — souvent 24 à 72 heures avant l'ajout au KEV. Pour une organisation de taille moyenne, l'abonnement à un de ces feeds combiné avec KEV et le suivi des alertes CERT-FR couvre 95 pour cent des situations critiques. C'est un investissement de quelques dizaines de milliers d'euros par an qui économise potentiellement plusieurs ordres de grandeur en cas d'incident évité.

Conclusion

Le Patch Tuesday n'est pas mort par décret, il est mort par obsolescence du modèle de menace. Personne ne va l'abolir officiellement, mais les organisations qui continuent à fonctionner exclusivement sur ce rythme se condamnent à finir dans la liste des leaks ShinyHunters ou Akira de 2027. La transition vers un patching en deux vitesses, avec voie express documentée pour les CVE critiques exploitées et capacité de mitigation compensatoire, est désormais la base d'une posture défensive crédible. Le retard accumulé est rattrapable, mais il faut commencer maintenant et au bon niveau hiérarchique.

Vers un modèle de patching continu : ce que M-Trends 2026 implique pour les équipes sécurité

Le rapport M-Trends 2026 de Mandiant quantifie une réalité que les praticiens de la sécurité observaient déjà depuis 2023 : 28,3 % des CVE publiées en 2025 exploitées dans les 24 heures. Ce chiffre ne sert pas à alarmer — il sert à calibrer correctement les investissements en gestion des vulnérabilités.

La mort du Patch Tuesday : cinq symptômes

Le Patch Tuesday est mort non pas d'une seule cause, mais d'une accumulation de facteurs qui ont progressivement rendu le modèle mensuel inadapté :

1. La PoC economy : des développeurs spécialisés publient des proof-of-concept pour les CVE critiques dans les heures suivant leur divulgation, souvent sur GitHub ou dans des outils offensifs comme Metasploit. Le délai entre "CVE publiée" et "exploit disponible publiquement" est passé de semaines à heures.
2. Nuclei et l'industrialisation des scans : l'écosystème Nuclei compte des milliers de templates de détection de CVE, maintenus par une communauté active. Un nouveau template pour une CVE critique est créé et partagé en quelques heures. Des botnets entiers l'exécutent sur l'ensemble de l'espace d'adressage IPv4.
3. Le marché des zero-days : des courtiers comme Zerodium achètent des zero-days et les revendent à des acteurs étatiques ou criminels. Ces exploits sont souvent utilisés intensivement avant la découverte — et la fenêtre de patch post-découverte est minuscule.
4. Les délais de patch des éditeurs tiers : Microsoft peut publier un patch le deuxième mardi du mois, mais les éditeurs de logiciels tiers (équipements réseau, solutions métier, frameworks web) n'ont pas de cycle de patch coordonné. Leurs vulnérabilités s'accumulent entre deux releases.
5. La complexité des environnements hybrides : les applications cloud, les conteneurs, les microservices ont des cycles de vie différents. Un patch qui fonctionne en VM prend 3 semaines à traverser le pipeline CI/CD d'une application containerisée — pendant lesquelles la production reste vulnérable.

Architecture d'un programme de remédiation des vulnérabilités adapté à 2026

Un programme de remédiation efficace en 2026 n'est plus centré sur un cycle mensuel mais sur une matrice de priorité dynamique, alimentée en temps réel par des sources de threat intelligence :

• Tier 1 — Réponse en moins de 24h : CVE CVSS ≥ 9 avec PoC public ET actif sur des actifs exposés Internet. Processus d'urgence activé en dehors des cycles normaux. Approbation accélérée pour le déploiement du patch ou mise en place de mesures compensatoires immédiates (WAF rule, désactivation du service).
• Tier 2 — Réponse en moins de 7 jours : CVE CVSS ≥ 7 exploitées dans le catalogue KEV CISA, ou CVE ≥ 9 sans PoC connu. Inclut aussi les actifs sensibles internes (contrôleurs de domaine, serveurs de messagerie, solutions de sauvegarde).
• Tier 3 — Cycle de remédiation bimensuel : CVE CVSS 4 à 7 sur les serveurs, postes de travail et environnements de développement. Intégré dans les fenêtres de maintenance planifiées.
• Tier 4 — Cycle trimestriel : CVE basse criticité, actifs non critiques, environnements de test. Rationalisation par lot pour minimiser les perturbations.

Intégration de la gestion des vulnérabilités dans le SMSI ISO 27001

La gestion des vulnérabilités techniques est couverte par le contrôle 8.8 de l'Annexe A ISO 27001:2022. Ce contrôle exige que l'organisation obtienne des informations sur les vulnérabilités techniques des systèmes utilisés, évalue son exposition et prenne les mesures appropriées. En pratique, cela implique :

• Un processus documenté de gestion des vulnérabilités avec des SLA de remédiation par niveau de criticité
• Un outillage de scan de vulnérabilités (Tenable Nessus, Qualys, Rapid7 InsightVM) avec une couverture exhaustive du périmètre
• Des indicateurs mesurables : nombre de CVE critiques ouvertes, délai moyen de remédiation par tier, couverture du scan
• Une revue périodique des résultats en comité de sécurité

Foire aux questions — Gestion des vulnérabilités et Patch Tuesday

Faut-il vraiment patcher en 24h pour les CVE critiques ?

Pas nécessairement — cela dépend de l'exposition. Une CVE CVSS 9.8 sur un composant que vous n'avez pas déployé, ou qui n'est accessible que depuis votre réseau interne sécurisé, ne nécessite pas une réponse en 24h. Ce qui nécessite une réponse en 24h, c'est une CVE activement exploitée (dans le catalogue KEV CISA ou signalée par CERT-FR) sur un actif que vous avez exposé sur Internet. La cartographie de vos actifs exposés est donc le prérequis absolu d'une politique de remédiation efficace.

Comment justifier auprès du management l'investissement dans un outillage de gestion des vulnérabilités ?

Quantifiez le coût d'un incident ransomware pour votre organisation (coût de remédiation, arrêt de production, impact réglementaire) et mettez-le en regard du coût annuel d'une solution de gestion des vulnérabilités (Tenable Nessus Professional coûte moins de 5 000€/an pour 256 actifs). La démonstration d'une CVE critique non patchée sur un de vos actifs exposés est souvent plus efficace qu'un discours théorique. Utilisez les résultats d'un premier scan gratuit (Tenable propose des versions d'évaluation) pour générer un rapport concret de l'exposition actuelle.