CVSS 10 ne veut plus rien dire : plaidoyer pour une gestion des vulnérabilités basée sur l'exploitation réelle

En juillet 2026, Adobe ColdFusion reçoit un patch CVSS 10.0. Soixante-douze heures plus tard, un PoC public circule. Deux minutes après, des honeypots détectent les premières attaques. Et pourtant, des milliers d'instances restent non patchées. Ce n'est pas un problème de complexité technique — c'est un problème de prioritisation brisée. Et le CVSS en est une cause directe.

Le CVSS : un système conçu pour une autre époque

Le Common Vulnerability Scoring System a été conçu en 2005 par le NIST et le FIRST pour offrir un langage commun de mesure de la sévérité des vulnérabilités. Version 2, puis 3.0, puis 3.1, puis 4.0 sorti en 2024 — la formule a évolué, les critères de vecteur d'attaque, complexité, privilèges requis, interaction utilisateur et impact sur la confidentialité/intégrité/disponibilité ont été affinés. Le résultat est un score de 0 à 10, universel, consigné dans chaque fiche NVD du NIST.

En théorie, un score de 10.0 devrait déclencher une réponse immédiate. En pratique, voici ce qui se passe dans la plupart des organisations de taille moyenne en 2026 : l'équipe sécurité reçoit une alerte automatique "CVSS 10 détecté". Elle ouvre un ticket. Elle le classe P1. La prochaine fenêtre de maintenance est dans 12 jours. Le patch est planifié. Les 12 jours passent. Mission accomplie.

Sauf que pendant ces 12 jours, CVE-2026-48282 (ColdFusion, CVSS 10.0) était exploitée activement depuis le jour 3. L'organisation était compromise depuis 9 jours au moment d'appliquer le patch. Et ça, le CVSS ne le dit pas.

Le problème fondamental du CVSS : il mesure la sévérité théorique d'une vulnérabilité dans les conditions les plus favorables à un attaquant, mais n'intègre pas la dimension temporelle de l'exploitation réelle. Un CVSS 10 sans exploit connu et un CVSS 10 avec des kits d'exploitation automatisés actifs depuis 48h devraient appeler des réponses radicalement différentes. Pourtant, ils produisent le même score, le même ticket P1, la même fenêtre de maintenance à J+12.

L'inflation des scores critiques : quand tout est urgent, rien ne l'est

Le Patch Tuesday de juillet 2026 de Microsoft a corrigé 622 CVE, dont une cinquantaine de critiques (CVSS 9.0+) selon les analyses de Rapid7 et Tenable. L'année précédente, on dépassait rarement 150 CVE par mois. Nous atteignons des niveaux records qui auraient été impensables en 2020.

Ce volume génère un phénomène bien documenté : la fatigue des alertes. Quand un SOC reçoit 50 alertes CVSS 9+ par mois, il s'adapte par nécessité. Les équipes développent des heuristiques informelles : "Si c'est Windows et qu'on a une MAJ mensuelle planifiée, on attend." "Si c'est un composant legacy qu'on remplace dans un an, on priorise autre chose." "Si l'éditeur dit 'pas d'exploitation connue', on peut attendre J+30."

Ces heuristiques ne sont pas irrationnelles — elles sont des mécanismes d'adaptation à un flux d'alertes qui dépasse les capacités humaines de réponse. Mais elles créent des angles morts dangereux précisément là où les attaquants opèrent : dans les 72 premières heures après publication d'un PoC, sur des composants que les équipes pensent à faible risque car "jamais vu d'exploitation dans notre secteur".

En 2026, l'inflation des CVE critiques a conditionné les équipes à traiter le CVSS 10 comme un P1 ordinaire plutôt qu'une urgence absolue. Et les attaquants misent précisément sur ce décalage entre la note et la réaction.

La révolution silencieuse : le catalogue KEV de la CISA

En novembre 2021, la CISA américaine a lancé son catalogue KEV — Known Exploited Vulnerabilities. Le principe : lister les CVE pour lesquelles une exploitation active dans la nature a été confirmée. Pas de score, pas d'algorithme. Un critère binaire : est-ce qu'on a vu cette faille utilisée par de vrais attaquants dans de vraies attaques ?

En juillet 2026, le catalogue KEV contient plus de 1 200 entrées — beaucoup moins que les dizaines de milliers de CVE publiées chaque année dans le NVD. Et c'est précisément là que réside sa valeur : le KEV représente les vulnérabilités qui comptent vraiment d'un point de vue opérationnel défensif.

Des études de Tenable et Rapid7 en 2025 ont montré que la corrélation entre CVSS élevé et exploitation active est bien plus faible qu'on ne le suppose : sur les CVE CVSS 9+ publiées entre 2022 et 2024, moins de 8% ont fait l'objet d'une exploitation documentée. À l'inverse, certaines CVE avec des scores modérés (6.0-7.5) ont été massivement exploitées parce qu'elles ciblaient des composants répandus et simples à exploiter — mais le score n'avait pas déclenché d'alerte P1.

La règle que j'applique et recommande : le catalogue KEV prime sur le CVSS pour la priorisation opérationnelle. CVE dans le KEV = urgence absolue, SLA 24-48h maximum. CVE CVSS 10 sans KEV = cycle accéléré J+7. Ce n'est pas une règle parfaite, mais elle est bien plus proche de la réalité des attaquants que la note théorique.

La fenêtre d'exploitation : un problème de temps, pas de score

L'autre dimension que le CVSS ignore : la vitesse du cycle d'exploitation. En 2020-2021, le délai moyen entre publication d'une CVE critique et première exploitation réelle était de 15 à 30 jours (données Mandiant). En 2024-2025, il est tombé à 5-7 jours. En 2026, pour les vulnérabilités avec PoC public, nous parlons d'heures.

CVE-2026-48282 (ColdFusion) : PoC publié le 2 juillet, premières attaques quelques minutes plus tard. CVE-2026-39808 (FortiSandbox) : exploitation active sous 48h. CVE-2026-15409/15410 (SonicWall) : zero-days exploités avant même la publication du patch.

Cette accélération résulte de plusieurs facteurs convergents :

• L'outillage d'exploitation industrialisé : des frameworks comme Metasploit ou Nuclei permettent d'intégrer un nouveau PoC en quelques heures et de le déployer à l'échelle internet automatiquement.
• Le scanning Internet continu : Shodan, Censys et leurs équivalents offensifs permettent d'identifier en quelques minutes toutes les instances exposées d'un produit vulnérable dans le monde entier.
• L'IA accélère le développement d'exploits : des études académiques de 2025 ont démontré que des LLM spécialisés peuvent générer des exploits fonctionnels dans des délais divisés par 3 à 5 par rapport au développement humain classique.
• Les marchés de vulnérabilités : des acteurs revendent des zero-days avant que les éditeurs ne soient informés, comprimant encore la fenêtre de réaction défensive.

Dans ce contexte, une politique de patch management sur cycles mensuels est structurellement inadaptée pour les CVE avec PoC public. Le délai médian entre disponibilité d'un exploit et premier compromis réussi observé dans des incidents réels traités ces deux dernières années est inférieur à 96 heures. Un cycle mensuel = exposition garantie de 3 à 28 jours selon la date de publication. Inacceptable pour une CVE dans le KEV.

Ce que les organisations font mal concrètement

Après plusieurs années d'audits et de réponse à incident, j'observe les mêmes cinq dysfonctionnements récurrents.

1. L'inventaire des actifs est incomplet. On ne peut pas patcher ce qu'on ne sait pas qu'on possède. CVE-2026-48282 en est l'exemple parfait : des milliers d'instances ColdFusion tournent dans des environnements oubliés — portails de test jamais supprimés, applications héritées de rachats, intranets maintenus par des équipes parties. Ces instances ne figurent pas dans le CMDB, ne reçoivent pas les alertes, et sont souvent celles que trouvent en premier les scans offensifs automatisés.

2. Le "pas d'exploitation connue" justifie des délais dangereux. "Il n'y a pas encore d'exploitation, on peut attendre la prochaine fenêtre." Ce raisonnement était valable en 2015. En 2026, pour une CVE avec PoC sur un composant exposé internet, l'exploitation active se compte en heures. La décision de reporter doit intégrer cette réalité.

3. La gestion des exceptions est opaque et non revisitée. Quand un patch ne peut pas être appliqué immédiatement, une exception est documentée avec date d'expiration et contrôles compensatoires. En pratique : les exceptions s'accumulent, les dates passent sans revue, les contrôles ne sont jamais vérifiés. Résultat : un parc avec des vulnérabilités critiques non patchées depuis des mois, couvertes par une justification administrative qui masque le risque réel.

4. L'exposition internet n'est pas différenciée. Une instance vulnérable exposée sur internet et la même instance sur un réseau interne isolé ne posent pas le même risque. La priorité de patch doit être modulée en fonction de l'exposition réseau réelle : 24h pour ce qui est exposé internet, 7 jours pour ce qui est interne avec accès indirect, cycle normal pour ce qui est réellement isolé.

5. Les tests de régression bloquent les patches d'urgence. Pour les composants critiques, appliquer un patch peut casser une fonctionnalité. Les équipes infrastructure refusent légitimement de patcher sans tests. Mais les cycles de tests sont calés sur des fenêtres de maintenance, pas sur des délais de sécurité. La solution : des environnements de préproduction bien entretenus, des tests automatisés, et une pré-qualification des patches critiques dès leur publication.

Construire une priorisation adaptée à 2026

Voici le framework que j'applique, volontairement simple pour être opérationnel dans une organisation sans équipe dédiée de 20 personnes.

Tier 1 — Urgence absolue (SLA : 24h) : Toute CVE dans le catalogue KEV de la CISA ciblant un composant exposé internet. Ces cas ne passent pas par le change management ordinaire. Ils déclenchent un processus d'urgence avec approbation accélérée. Si le patch n'est pas disponible sous 24h : coupure réseau, désactivation du service, ou mise derrière WAF avec règle temporaire.

Tier 2 — Priorité haute (SLA : 7 jours) : CVE CVSS 9.0+ avec PoC public mais pas encore dans le KEV, OU dans le KEV sur des actifs internes non exposés internet. Cycle accéléré avec fenêtre dédiée dans la semaine.

Tier 3 — Priorité normale (SLA : 30 jours) : CVE CVSS 7.0-8.9, sans PoC public, hors KEV. Intégration dans le cycle mensuel standard.

Tier 4 — Backlog (SLA : 90 jours) : CVE sous 7.0, internes uniquement, conditions d'exploitation complexes.

Ce framework découple la priorité du score CVSS brut pour la connecter à l'exploitation réelle et à l'exposition réseau. Il réduit drastiquement le nombre de cas traités en urgence absolue — dans la pratique, les CVE simultanément dans le KEV ET ciblant des actifs exposés internet dans votre parc sont bien moins nombreuses que les CVE CVSS 9+ hebdomadaires.

Il est complété par trois processus non négociables :

• Un inventaire des actifs exposés internet tenu en temps réel, couplé à un outil de scan continu capable de corréler les nouvelles CVE avec l'inventaire en quelques minutes.
• Une veille KEV quotidienne : s'abonner au flux RSS du catalogue CISA KEV et configurer une alerte automatique croisant chaque nouvelle entrée avec l'inventaire des logiciels du parc.
• Un processus d'urgence cybersécurité documenté et testé, avec contacts d'astreinte identifiés, chaîne d'approbation raccourcie, et communications préparées pour les parties prenantes métier.

Le cas particulier des technologies legacy

ColdFusion nous rappelle que des milliers de systèmes critiques fonctionnent en 2026 sur des technologies dont la base d'utilisateurs a considérablement rétréci, dont les équipes de développement sont parties, et dont la mise à jour est perçue comme trop risquée ou trop coûteuse.

Ces systèmes legacy concentrent des vulnérabilités historiques et récentes sur des composants peu surveillés. Et ils sont souvent en accès internet direct parce qu'ils hébergent des portails publics jamais migrés. La combinaison la plus dangereuse qui soit.

La solution n'est pas de patcher indéfiniment des technologies en fin de vie — c'est d'établir un plan de sortie documenté, priorisé et financé, et de mettre en place des contrôles compensatoires forts en attendant : isolation réseau maximale, WAF devant tout service exposé, surveillance renforcée des logs, revue de sécurité semestrielle. Un système legacy sans plan de remplacement et sans contrôles compensatoires n'est pas un risque acceptable — c'est une dette de sécurité qui finira par se régler dans les mauvaises conditions.

Sur les audits que je réalise, les composants legacy non patchés accessibles depuis internet constituent systématiquement l'un des vecteurs d'entrée les plus faciles. Pas parce que les failles sont sophistiquées, mais parce que personne ne les surveille vraiment. Un attaquant qui scanne l'internet à la recherche d'instances ColdFusion 2023 non patchées en juillet 2026 est face à des milliers de cibles. Il lui suffit d'en exploiter une.

Pourquoi les équipes de direction résistent encore

Une réalité terrain à nommer : même avec un framework clair et des outils adaptés, la gestion des vulnérabilités se heurte à des résistances organisationnelles.

Le premier obstacle est le coût perçu du patch vs le risque perçu. Un patch d'urgence peut coûter une demi-journée d'interruption de service et mobiliser 3 personnes. Un compromis que l'attaquant ne lancera peut-être jamais. Dans ce calcul, le risque est abstrait et futur ; le coût est concret et immédiat. Les organisations qui ont déjà subi un incident ransomware ont une perception très différente de ce calcul. Les autres font confiance à leur chance.

Le second obstacle est la fragmentation des responsabilités. La sécurité identifie, l'infrastructure patche, les équipes applicatives valident, le management approuve les fenêtres. Chaque maillon peut créer un délai. Et personne n'est individuellement responsable du délai global. L'accountability est diluée — c'est l'une des raisons pour lesquelles les SLA de patch sont si souvent dépassés sans conséquence interne.

La solution passe par la désignation d'un vulnerability owner par périmètre applicatif, avec un suivi des SLA et une escalade nominative en cas de dépassement. Ce n'est pas une question d'outils — c'est une question de gouvernance.

Conclusion

Le CVSS continuera d'exister parce qu'il remplit une fonction utile de communication. Mais en 2026, s'appuyer uniquement sur lui pour prioriser les actions de sécurité, c'est naviguer dans une tempête avec une carte météo vieille d'une semaine. L'exploitation des vulnérabilités se mesure maintenant en heures. Le catalogue KEV de la CISA, l'exposition réseau et la disponibilité d'un PoC sont les trois variables qui doivent piloter vos SLA de patch management.

ColdFusion CVSS 10 exploité en 2 minutes. Fairlife infiltré 6 semaines. Conduent compromis 84 jours. Les incidents de juillet 2026 partagent un dénominateur commun : une réponse trop lente face à des attaquants qui opèrent en temps réel. Les outils et les méthodes pour répondre à cette vitesse existent. Ce qui manque dans la plupart des organisations, c'est la décision d'en faire une priorité — avant que l'incident suivant ne l'impose.