CVSS 9.x sans exploitation active : comment prioriser les patches sans se noyer dans les alertes

CVE-2026-21589, CVSS 9.3, publié hier par Atlassian. CVE-2026-63277, CVSS 8.5, LibreOffice. CVE-2026-88779, Citrix, ajouté au catalogue KEV de la CISA. Trois vulnérabilités critiques en 48 heures. Votre ticket de priorité se remplit, votre équipe commence à peine sa journée. Laquelle traiter en premier ? Laquelle peut attendre le prochain cycle de maintenance planifié ? C'est la vraie question opérationnelle de 2026 — et le score CVSS seul ne vous donnera pas la réponse.

Ce que le CVSS mesure — et ce qu'il ne mesure pas

Le Common Vulnerability Scoring System (CVSS) est un système de notation standardisé publié par le Forum of Incident Response and Security Teams (FIRST). Il évalue une vulnérabilité sur une échelle de 0 à 10 en combinant des métriques techniques : vecteur d'attaque (réseau, adjacent, local), complexité d'exploitation, privilèges requis, interaction utilisateur, portée, et impacts sur la confidentialité, l'intégrité et la disponibilité.

C'est un outil utile pour une chose précise : comparer la sévérité intrinsèque d'une vulnérabilité dans des conditions théoriques optimales pour l'attaquant. Un CVSS 9.3 signifie : si cette faille est exploitée dans les meilleures conditions possibles contre un système idéalement cible, l'impact serait très élevé. Ce n'est pas la même chose que : cette faille sera exploitée dans votre environnement demain matin.

Ce que le CVSS ne mesure pas :

• L'exploitabilité réelle : est-ce qu'un exploit opérationnel existe ? Est-il public ? Est-il utilisé activement par des attaquants dans la nature ?
• Votre exposition spécifique : avez-vous ce produit dans votre infrastructure ? Est-il exposé sur internet ? Quelle version faites-vous tourner ?
• La valeur de l'actif : ce serveur héberge-t-il votre production, un environnement de test, ou un système interne peu critique ?
• La disponibilité d'un patch : un correctif est-il disponible ? Quelles mitigations existent si ce n'est pas le cas ?
• Le contexte de votre secteur : votre industrie est-elle activement ciblée par les acteurs qui exploitent cette faille ?

Ces cinq dimensions sont invisibles dans un score CVSS. Et pourtant, ce sont elles qui déterminent si vous devez patcher en urgence ou si vous pouvez attendre le prochain cycle de maintenance. La confusion entre sévérité théorique et risque opérationnel réel est l'une des sources les plus fréquentes d'épuisement des équipes sécurité.

L'explosion des CVSS critiques : le problème du bruit

En 2026, environ 30 000 CVE ont été publiés depuis le début de l'année, dont plus de 4 500 avec un score CVSS supérieur ou égal à 9.0. Soit en moyenne 15 à 20 vulnérabilités « critiques » publiées chaque semaine. Si votre politique de sécurité stipule que toute CVE critique doit être patchée en 72 heures, vous avez un problème structurel : vous ne pouvez pas honorer cette politique tout en maintenant le reste des opérations.

C'est le paradoxe des systèmes de sécurité mal calibrés : plus les alertes sont nombreuses, moins les équipes les prennent au sérieux. La fatigue d'alerte est documentée depuis les travaux de Ponemon Institute et n'a fait qu'empirer avec l'augmentation du volume de CVE. Des études de Gartner (rapport 2025 sur la gestion des vulnérabilités) montrent que 62 % des équipes SOC avouent prioriser les patches en fonction des délais contractuels ou de la visibilité des incidents plutôt que d'un processus de risque structuré.

Le résultat est paradoxal : des équipes épuisées patchent des vulnérabilités théoriques à faible risque d'exploitation réel, pendant que des failles effectivement exploitées dans la nature restent non corrigées pendant des semaines faute de visibilité suffisante. C'est exactement l'inverse de ce que la sécurité doit produire.

EPSS : la probabilité d'exploitation réelle

Depuis 2022, le FIRST maintient un indicateur complémentaire au CVSS : l'Exploit Prediction Scoring System (EPSS). Son objectif est de prédire la probabilité qu'une vulnérabilité soit exploitée dans les 30 prochains jours, en s'appuyant sur des données de threat intelligence temps réel : présence de PoC publics, mentions dans des forums cybercriminels, observations de scans actifs, corrélation avec des familles de malwares connues.

L'EPSS s'exprime en pourcentage. Un score de 0,93 signifie que 93 % des vulnérabilités comparables ont été exploitées dans les 30 jours suivant leur publication. Un score de 0,003 signifie une probabilité de 0,3 % — une vulnérabilité théoriquement critique mais pratiquement ignorée par les attaquants.

La divergence entre CVSS et EPSS est frappante dans la pratique. CVE-2026-21589 (Atlassian, CVSS 9.3) n'avait pas encore de score EPSS élevé au moment de la publication — aucune exploitation confirmée, PoC technique publié mais pas d'exploit weaponized connu. En revanche, CVE-2026-88779 (Citrix NetScaler, CVSS 7.5) figurait dans le catalogue KEV de la CISA dès la semaine de sa publication — exploitation active confirmée, intégrée dans des campagnes ciblant des infrastructures critiques. Laquelle doit être patchée en 72h ? La réponse n'est pas celle que vous indique le CVSS seul.

Le catalogue KEV de la CISA : le filtre le plus fiable

Créé en novembre 2021, le catalogue Known Exploited Vulnerabilities (KEV) de la CISA est devenu la référence mondiale pour identifier les vulnérabilités activement exploitées. Une CVE entre dans le catalogue KEV uniquement lorsque la CISA dispose de preuves crédibles d'exploitation active — pas seulement un PoC académique, mais une utilisation réelle dans des attaques observées.

Le catalogue KEV couvre aujourd'hui plus de 1 200 CVE. En 2026, environ 180 nouvelles entrées ont été ajoutées depuis le début de l'année, soit 3 à 4 par semaine. C'est beaucoup moins que les 15 à 20 CVSS >= 9.0 publiées sur la même période. Si votre ressource de patching est limitée, le KEV est votre premier filtre : une CVE qui y figure doit être traitée en priorité absolue, quelle que soit son score CVSS nominal.

La règle qui en découle pour les organisations avec des ressources de patching contraintes :

1. KEV CISA : priorité critique, patch sous 72h (les agences fédérales américaines ont 21 jours maximum, mais 72h est le standard que j'observe chez les organisations les mieux préparées)
2. EPSS > 0,50 + actif exposé sur internet : priorité haute, patch sous 7 jours
3. CVSS >= 9.0 + pas dans KEV + EPSS bas : priorité normale, prochain cycle de maintenance planifié
4. Tout le reste : backlog, traité selon capacité

Votre exposition spécifique : le facteur décisif

Un CVSS 10.0 sur un produit que vous n'utilisez pas est un bruit à ignorer. Un CVSS 6.5 sur un service exposé en frontal sur internet, utilisé par 500 collaborateurs, avec un EPSS de 0,78, est une urgence. Cette réalité évidente est pourtant régulièrement ignorée dans les organisations qui s'appuient uniquement sur les bulletins de sécurité des éditeurs sans les croiser avec leur inventaire d'actifs.

La condition préalable à tout processus de priorisation efficace est un inventaire d'actifs précis et à jour. Vous devez savoir : quels logiciels sont installés sur quels systèmes en quelle version, quels systèmes sont exposés sur internet, quelle est la criticité business de chaque système, qui a accès à quoi avec quels privilèges.

Sans cet inventaire, toute tentative de priorisation des patches est aveugle. Dans les environnements sans CMDB (Configuration Management Database) à jour — la réalité de la majorité des PME et d'une partie des ETI — la première étape est souvent un scanner de vulnérabilités comme Qualys, Tenable Nessus ou l'outil open-source Greenbone, couplé à une revue manuelle des actifs exposés sur internet via Shodan ou Censys.

Les outils pour construire votre processus

Plusieurs ressources gratuites permettent de mettre en place ce processus sans budget additionnel :

• Catalogue KEV CISA : accessible publiquement, mis à jour en continu, disponible au format JSON pour intégration dans vos outils. La clé de voûte de votre priorisation.
• EPSS (first.org/epss) : API disponible, scores mis à jour quotidiennement. S'intègre dans la plupart des scanners de vulnérabilités modernes.
• NVD (National Vulnerability Database) : base de référence pour les détails techniques des CVE, les vecteurs CVSS, et les références vers les advisories fournisseurs.
• CERT-FR : pour les organisations françaises, les bulletins d'alerte et d'avis incluent une analyse contextuelle souvent plus pertinente que le seul score CVSS.
• Vulncheck KEV+ : extension du catalogue KEV avec des données de threat intelligence supplémentaires, notamment sur les acteurs qui exploitent chaque CVE.

Le cas pratique : les trois CVE de cette semaine

Appliquons la règle à l'actualité de la semaine pour illustrer concrètement le processus.

CVE-2026-88779 (Citrix NetScaler, CVSS 7.5) : dans le catalogue KEV CISA, exploitation active confirmée dans des campagnes ciblant des infrastructures critiques. Malgré un CVSS « seulement » de 7.5, c'est la priorité absolue de la semaine. Règle 72h si vous avez du NetScaler exposé.

CVE-2026-21589 (Atlassian Data Center, CVSS 9.3) : pas encore dans le KEV, pas d'exploitation confirmée dans la nature. EPSS probablement modéré à ce stade (PoC technique publié, pas d'exploit weaponized connu). Instance Atlassian exposée sur internet : règle 7 jours. Instance uniquement en interne derrière VPN : règle 30 jours.

CVE-2026-63277 (LibreOffice, CVSS 8.5) : PoC public, exploitation via phishing possible, mais nécessite interaction utilisateur et Java activé. Pas dans le KEV. Règle 30 jours pour les organisations avec filtrage email robuste ; 7 jours pour les environnements avec population à risque élevé (services financiers, RH, direction).

Ce classement est à l'opposé de ce que donnerait un tri par score CVSS brut (9.3 > 8.5 > 7.5). C'est là toute la valeur d'un processus structuré.

Conclusion

La priorisation des patches n'est pas un problème technique. C'est un problème de décision sous contrainte de ressources avec une information incomplète. Le CVSS vous donne la sévérité théorique. Le KEV et l'EPSS vous donnent la dimension opérationnelle — ce qui se passe réellement dans la nature. Votre inventaire d'actifs vous donne la dimension contextuelle — ce que vous avez à protéger.

En 2026, avec 30 000 CVE par an, il est impossible de tout patcher en temps réel. La bonne question n'est pas « comment patcher tout ce qui est critique » — c'est impossible. La bonne question est : « comment m'assurer que les vulnérabilités qui seront exploitées contre moi dans les 30 prochains jours sont bien corrigées ? » La règle 72h/7j/30j, combinée au KEV et à l'EPSS, est une réponse opérationnelle directement applicable à cette question.