Délai de patch : le KPI que personne ne surveille en cyber

Deux actualités de cette semaine posent crûment la même question. D'un côté, PHP2Shell exploité 72 heures avant même sa publication officielle — avec 1 156 attaques en 48h sur 70 organisations. De l'autre, des groupes ransomware qui continuent d'exploiter CVE-2026-0257 sur PAN-OS GlobalProtect… cinq mois après la publication du patch. Ces deux histoires ne parlent pas de la même faille. Elles parlent du même problème : votre délai de patch révèle en chiffres votre véritable niveau de maturité cyber.

PHP2Shell : quand l'exploitation précède la divulgation

Le 17 octobre 2026, trois jours avant la publication officielle de CVE-2026-109618 et CVE-2026-109619, Amazon Threat Intelligence documente une première tentative d'exploitation. La faille n'était pas encore publique. Le patch n'existait pas encore. Et quelqu'un, quelque part, savait déjà.

Ce scénario illustre une réalité souvent méconnue des équipes sécurité qui raisonnent uniquement en termes de NVD et de flux CVE : la fenêtre de vulnérabilité ne commence pas à la publication d'un CVE. Elle commence au moment où un acteur malveillant — ou un chercheur avec de mauvaises intentions — découvre la faille. La divulgation coordonnée rend la faille publique, souvent au même moment où elle rend l'exploit accessible à des acteurs moins sophistiqués. Dans le cas de PHP2Shell, la divulgation a déclenché une vague d'exploitation massive : 1 156 tentatives en 48 heures, 156 IP uniques, 70 organisations ciblées. Ces chiffres émanent uniquement du réseau de honeypots de Zscaler — une fraction de la réalité.

La surface PHP est vertigineuse. Selon W3Techs, PHP est le langage serveur de 77 % des sites web dont la technologie est identifiable. WordPress seul représente 43 % du web mondial. Drupal, Joomla, Laravel, Symfony, Magento, WooCommerce, des milliers d'ERP et d'applications métier sur mesure : tout cela tourne sur PHP. La plupart de ces installations sont gérées par des équipes sans processus de patch management formalisé pour les mises à jour de l'interpréteur PHP. "On met à jour PHP quand on fait une mise à jour globale du serveur" — cette phrase, entendue lors d'audits, résume le problème.

Le délai entre la publication du patch (21 octobre) et son application effective dans une organisation médiane est estimé — sur la base des données historiques d'incidents comparables comme Log4Shell — entre 15 et 45 jours. Pour les organisations sans processus formalisé, ce délai peut s'étendre à plusieurs mois. C'est précisément cette inertie que les attaquants exploitent : ils savent que la fenêtre d'opportunité est large, et ils ont automatisé le scan des cibles vulnérables à grande échelle.

PHP2Shell est un cas d'école en termes de vélocité d'exploitation. Mais il soulève une question pratique : dans votre organisation, combien de temps s'écoulerait-il entre la publication d'un CVE critique sur PHP et son application effective en production ? Si vous n'avez pas de réponse chiffrée à cette question, vous n'avez probablement pas de KPI de patch management.

GlobalProtect : 5 mois de fenêtre ouverte

CVE-2026-0257, publiée le 13 mai 2026 par Palo Alto Networks, est à l'opposé du spectre temporel. Ce n'est pas une faille exploitée avant son patch — c'est une faille dont le patch a été ignoré pendant cinq mois par une fraction significative des organisations concernées. La CISA l'a ajoutée à son catalogue KEV dès le 29 mai, avec une deadline de remédiation au 1er juin pour les agences fédérales américaines. Malgré cela, fin octobre 2026, les groupes Qilin et Settra continuent d'exploiter CVE-2026-0257 pour s'introduire dans des réseaux d'entreprise via des sessions VPN GlobalProtect non autorisées.

La question n'est donc pas : "pourquoi n'y a-t-il pas eu de patch ?" Il y en avait un. La question est : "pourquoi autant d'organisations n'ont-elles pas appliqué un patch critique disponible depuis 5 mois ?" Les post-mortems d'incidents font ressortir plusieurs facteurs récurrents :

• La complexité opérationnelle de PAN-OS : mettre à jour un firewall Palo Alto n'est pas aussi simple qu'un apt upgrade. Cela nécessite une fenêtre de maintenance planifiée, des tests de régression sur les politiques de sécurité, et souvent une coordination avec les équipes réseau et les utilisateurs VPN.
• L'absence d'inventaire précis : combien d'organisations savent exactement quelles versions de PAN-OS tournent sur chacun de leurs équipements et si ces équipements exposent GlobalProtect sur Internet ?
• La priorisation par le bruit : en mai 2026, les équipes sécurité avaient déjà fort à faire avec d'autres CVE critiques. CVE-2026-0257 (CVSS 7.8) a pu être déprioritisée face à des failles notées 9.x ou 10.0. C'est le paradoxe du bruit d'alertes : trop d'urgences tuent la priorisation.
• La confiance mal placée dans les contrôles compensatoires : certains responsables sécurité ont pu considérer que le MFA déployé sur GlobalProtect suffisait à réduire le risque. CVE-2026-0257 contourne précisément le MFA en rejouant des cookies de session.

Résultat : cinq mois après la publication du patch, des organisations dans des secteurs critiques — hôpitaux, universités, administrations, opérateurs d'énergie — continuent de subir des intrusions via une porte d'entrée dont la clé est connue de tous. C'est la définition d'un échec de patch management.

Anatomie du délai de patch : les 5 étapes qui ralentissent la remédiation

Entre la publication d'un CVE et son application effective en production, cinq étapes créent chacune leur propre délai. Comprendre où votre organisation perd du temps est la condition pour le réduire.

1. Détection et identification (0 à J+3)
Comment votre équipe sécurité est-elle informée d'un nouveau CVE critique ? Via une alerte CERT-FR, un abonnement NVD, un flux threat intelligence, une notification vendor, ou un article partagé par un collègue ? Plus le canal de détection est informel, plus le délai s'allonge. Beaucoup d'organisations découvrent les CVE critiques avec 2 à 5 jours de retard sur les attaquants qui monitorent NVD en temps réel.

2. Évaluation et qualification (J+1 à J+7)
Une fois le CVE détecté, il faut qualifier son impact réel sur le parc. Le score CVSS seul ne suffit pas : une CVE 9.8 sur un logiciel que vous n'utilisez pas est moins urgente qu'une CVE 7.0 sur un équipement exposé sur Internet. Cette qualification nécessite un inventaire précis de l'existant — ce que la plupart des organisations n'ont pas. La phase d'évaluation peut durer plusieurs jours si l'équipe doit chercher manuellement quels systèmes sont affectés.

3. Tests de régression (J+2 à J+14)
Pour les environnements de production critiques, le patch doit être testé avant déploiement. C'est légitime. Mais trop souvent, le processus de test est trop long ou peu structuré : pas d'environnement de préproduction, pas de tests automatisés, pas de procédure de rollback testée. La complexité du test est proportionnelle à la complexité du système cible : patcher PHP sur un WordPress est rapide, patcher PAN-OS sur un firewall de production est une opération planifiée.

4. Processus de changement (J+3 à J+30)
Dans les organisations avec un processus ITIL formalisé, tout changement en production doit passer par un Change Advisory Board (CAB). Le rythme hebdomadaire du CAB crée mécaniquement un délai incompressible de 0 à 7 jours. Pour les changements urgents hors cycle, un processus de changement d'urgence doit exister — et être exercé régulièrement. Sinon, il ne sera pas utilisé même pour des CVE CVSS 10.0.

5. Déploiement et vérification (J+1 à J+7)
Le déploiement effectif, surtout sur un parc large, prend du temps. La vérification de l'application effective est souvent la phase la plus négligée. Des outils comme Ansible, Chef, Puppet ou des solutions spécialisées de patch management permettent d'automatiser et tracer cette étape. Sans eux, il est courant qu'une poignée de serveurs oubliés restent vulnérables pendant des mois.

Comment calculer et piloter votre MTTR-CVE

Le MTTR-CVE (Mean Time To Remediate — CVE) est l'indicateur synthétique qui résume votre capacité à répondre aux vulnérabilités. Il se calcule simplement : pour chaque CVE critique (CVSS >= 9.0 ou présente dans le catalogue KEV CISA), mesurez le délai en jours entre la date de publication du CVE et la date de déploiement effectif du correctif dans 100 % du parc concerné.

Les benchmarks du secteur en 2026, selon les données de Cyentia Research et Tenable :

Pour mesurer votre MTTR-CVE, vous avez besoin de deux sources de données : votre scanner de vulnérabilités (Nessus, Qualys, Rapid7 InsightVM) pour dater la première détection de la faille dans votre parc, et votre outil de gestion des changements (ServiceNow, Jira) pour dater la fermeture du ticket de remédiation. Si vous n'avez pas ces deux sources, commencez par là.

Un KPI secondaire utile : le patch rate à J+30. Quel pourcentage de CVE critiques avez-vous corrigé dans les 30 jours suivant leur publication ? Un objectif raisonnable pour une organisation de taille intermédiaire est 90 % à J+30 pour les CVE CVSS >= 9.0. Pour les vulnérabilités KEV CISA, l'objectif devrait être 100 % à J+15, quelle que soit la taille de l'organisation.

Ces indicateurs doivent être reportés au niveau COMEX ou RSSI. Le délai de patch n'est pas un indicateur purement technique — c'est un indicateur de risque business. CVE-2026-0257 exploitée pendant 5 mois dans des hôpitaux : c'est potentiellement des données patients compromises, des services médicaux interrompus, et des amendes RGPD. La valeur en euros d'un délai de patch est calculable. C'est d'ailleurs l'angle que recommande le guide NIS2 de l'ENISA pour présenter les risques cyber à des décideurs non techniques.

Les 3 pratiques qui font vraiment la différence

Après avoir accompagné plusieurs organisations dans la structuration de leur programme de gestion des vulnérabilités, j'ai identifié trois pratiques à impact disproportionné sur le MTTR-CVE. Elles ne nécessitent pas d'investissement massif — elles nécessitent de la rigueur organisationnelle.

Pratique 1 : abandonner le CVSS comme seul critère de priorisation

Le score CVSS mesure la sévérité théorique d'une faille dans des conditions idéales pour l'attaquant. Il ne mesure pas l'exploitabilité réelle dans votre contexte. Une CVE notée 9.8 sur un service non exposé sur Internet est moins urgente qu'une CVE 7.0 avec exploitation active confirmée et PoC public sur un service que vous exposez 24/7.

La pratique qui change tout : utiliser le catalogue KEV de la CISA comme premier filtre de priorisation. Si une vulnérabilité est dans le KEV, elle est exploitée en conditions réelles et doit être traitée dans les 15 jours, point final. Ce catalogue est public, gratuit, mis à jour quotidiennement. Il n'y a aucune raison de ne pas l'intégrer à votre processus de priorisation dès aujourd'hui. Une astuce supplémentaire : la métrique EPSS (Exploit Prediction Scoring System) de FIRST permet de quantifier la probabilité d'exploitation dans les 30 prochains jours, indépendamment du score CVSS. CVE-2026-0257 avait un EPSS élevé dès sa publication — un signal que les organisations auraient dû traiter en priorité même avec un CVSS de 7.8.

Pratique 2 : créer un track de patch d'urgence distinct du cycle normal

Votre processus de changement standard — avec son CAB hebdomadaire, ses tests de non-régression et ses fenêtres de maintenance planifiées — est adapté aux mises à jour de routine. Il n'est pas adapté aux CVE critiques avec exploitation active. Les organisations matures maintiennent deux tracks de remédiation : un track standard (délai 30 jours, processus ITIL classique) et un track d'urgence (délai 72 à 120 heures, processus allégé avec validation RSSI seul).

Le track d'urgence doit être documenté, exercé régulièrement (au moins une fois par trimestre en simulation), et connu de toutes les équipes impliquées. Il doit définir explicitement quels critères déclenchent son activation : présence dans le catalogue KEV, CVSS >= 9.0 avec PoC public, alerte CERT-FR de niveau "critique". S'il doit être inventé lors d'un incident, il est déjà trop tard.

Pratique 3 : automatiser la vérification post-patch

La phase la plus négligée du patch management est la vérification. Il ne suffit pas de lancer le déploiement du patch — il faut confirmer que le patch a été effectivement appliqué sur 100 % des assets concernés. Trop d'organisations s'arrêtent au déploiement sans vérifier systématiquement que tous les serveurs cibles ont bien été mis à jour.

Un re-scan de vulnérabilité ciblé sur les assets affectés, 24 à 48 heures après le déploiement, confirme la remédiation effective et détecte les assets oubliés. Cette étape devrait être intégrée comme étape obligatoire dans chaque ticket de remédiation de vulnérabilité critique. En pratique, les organisations qui automatisent cette vérification avec des outils de scan (Nessus, Qualys) réduisent leur MTTR-CVE de 30 à 50 % par rapport aux organisations qui vérifient manuellement ou ne vérifient pas du tout.

Conclusion

PHP2Shell exploité avant publication, GlobalProtect toujours ransomwaré 5 mois après le patch : ces deux incidents d'octobre 2026 ne sont pas des anomalies. Ils sont le résultat prévisible et mesurable d'un délai de patch mal maîtrisé. La bonne nouvelle : le MTTR-CVE est un indicateur actionnable. Il se mesure, il se pilote, et il s'améliore avec des processus adaptés. Si vous ne savez pas aujourd'hui quel est votre délai médian de remédiation des CVE critiques, c'est votre premier chantier. Pas un beau-à-avoir — un impératif opérationnel qui conditionne votre capacité à résister aux attaques de la semaine prochaine.