Patch Tuesday est mort : 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.