50 000 CVE en 2025, 70 000 en 2026 : pourquoi la priorisation est le vrai enjeu
Près de 50 000 vulnérabilités ont été publiées en 2025. Les forecasts tablent sur 70 000 pour 2026. Et pourtant, moins de 1 % d'entre elles seront réellement exploitées. Ce n'est plus un problème de détection mais c'est un problème de priorisation.
Cet article explique pourquoi le couple CVSS + EPSS, devenu le standard de fait, n'est plus suffisant pour décider quoi patcher, et ce qu'une approche moderne de priorisation devrait combiner pour rester utile en 2026.
Vingt ans à faire ce travail à la main
Notre constat, après vingt ans cumulés en cybersécurité offensive et au sein de CERT, est sans appel : la gestion des vulnérabilités telle qu'elle est pratiquée n'est plus tenable. Le volume explose, les contextes se multiplient (la stack d'un client, ses technos, son exposition), et une CVE critique pour l'un peut être totalement sans importance pour l'autre.
À force de répéter chaque matin le même exercice (ouvrir quinze sources, croiser, hiérarchiser, sortir une note pour chaque client sur ce qui méritait son attention dans les 24h) des patterns sont apparus. Quels signaux comptent vraiment, dans quel ordre, avec quelle pondération.
Le CVSS pose une question, mais ce n'est pas la bonne
Le bulletin hebdomadaire du CERT-FR du 30 mars 2026 listait 34 vulnérabilités classées critiques (CVSS > 9), dont une seule avec un code d'exploitation public. Autrement dit, 97 % du « critique » de la semaine n'avait, au moment de la publication, ni preuve de concept, ni exploitation observée, ni urgence opérationnelle.
Le CERT-FR fait un travail remarquable. Le problème est en amont. Le CVSS répond à : « À quel point cette faille est-elle théoriquement grave ? ». Pas à : « Est-ce que ça concerne mon SI et est-ce que c'est exploité maintenant ? ».
Deux exemples concrets illustrent ce décalage :
CVE-2026-20122 (Cisco SD-WAN Manager), CVSS 5.4
Sur la grille, c'est du medium : authentification requise, « écrasement de fichiers », pas de RCE directe. Cette vulnérabilité aurait été ignorée par un tri purement CVSS (toutes les CVE < 7.0 reportées au mois prochain).
Pourtant, la CISA la classe comme activement exploitée. Pourquoi ? Parce que les attaquants aiment les équipements qui pilotent des centaines, voire des milliers de routeurs SD-WAN dans un grand groupe 😈. La criticité réelle dépasse largement le score théorique.
CVE-2025-48983 (Veeam Backup), CVSS 10.0
Veeam est la cible n°1 des ransomwares : effacer les backups avant de chiffrer est un objectif central. Un CVSS à 10.0 sur ce composant, c'est censé déclencher la réunion de crise du vendredi soir 🚨.
Et pourtant cette CVE reste à un EPSS de 0,24 %. Pourquoi ? Un détail caché dans la description : « by an authenticated domain user ». L'attaquant a besoin d'un pied dans votre Active Directory pour l'exploiter. Cette CVE n'a jamais été exploitée publiquement, ni vu apparaître de PoC ou d'exploit.
Bilan : près de 50 000 vulnérabilités publiées en 2025, environ la moitié estampillées critiques par le CVSS, moins de 300 réellement exploitées. Moins de 1 %.
Et CVSS v4 dans tout ça ?
CVSS v4 a justement introduit un groupe de métriques Threat avec un indicateur d'Exploit Maturity (« Attacked », « POC », etc.), précisément pour répondre au reproche d'un score figé. C'est un vrai progrès conceptuel. Mais dans les faits, seules ~34 % des CVE publiées en 2026 portent un score v4, et les gros éditeurs comme Microsoft, Red Hat ou Oracle continuent à publier en v3.1. Et même quand un score v4 est publié, les métriques Threat, pourtant conçues pour évoluer après la divulgation, sont rarement mises à jour, faute d'émetteurs (CNAs) qui republient leurs vecteurs. Surtout, le base score v4 reste, par construction, sans contexte : il ne saura jamais si la techno concernée est présente dans votre stack. v4 fait un pas dans la bonne direction, mais ne change pas la nature du problème.
L'EPSS comble une partie du vide, mais pas tout
L'EPSS (Exploit Prediction Scoring System) prédit la probabilité d'exploitation à 30 jours. Sur le papier, c'est exactement ce dont on a besoin. En pratique, trois limites apparaissent rapidement :
Boîte noire. Quand une CVE passe de 0,4 % à 20 % en 48 heures, on ne sait pas pourquoi. Difficile de justifier une décision de patch à un client ou à son équipe sur un signal opaque.
Fiabilité prédictive limitée. Prédire l'exploitation est intrinsèquement difficile, et le score s'en ressent. Un score probabiliste seul ne peut pas porter une décision : il doit être recoupé avec des signaux factuels.
Biais structurel. L'EPSS s'appuie sur des télémétries majoritairement nord-américaines et évalue d'autant mieux une vulnérabilité que sa surface d'attaque est visible sur l'Internet ouvert. Conséquence concrète : sur les 45 CVE répertoriées sur le code propre de Stormshield (pare-feu français qualifié ANSSI), aucune n'a jamais dépassé 4 % d'EPSS. Non pas parce que le risque est nul, mais parce que l'EPSS regarde ailleurs.
Le volume explose, le temps d'exploitation se contracte
À la mi-2026, environ 23 000 CVE ont déjà été publiées depuis janvier, soit +32 % par rapport à la même période en 2025. Certaines prévisions tablent sur 70 000 CVE pour fin 2026 (Jerry Gamblin, Cisco Threat Detection & Response), à comparer aux 49 972 de 2025. Et ce chiffre date d'avant l'arrivée des nouveaux outils de découverte de vulnérabilités assistés par IA (Claude Mythos & Co), encore largement absents des forecasts actuels.
Le vrai problème se déplace : trouver les vulnérabilités n'est plus le goulot d'étranglement. Le goulot, c'est décider lesquelles patcher en premier, avant qu'elles ne soient exploitées. Et l'unité de temps a changé. En 2025, on parlait de jours avant exploitation. En 2026, on parle d'heures. Selon Zero Day Clock, le délai médian entre la publication et un code d'exploitation disponible est passé d'environ 20 jours à moins de 20 heures. Les attaquants n'ont plus la politesse d'attendre la fin du week-end.
Le vrai défi devient clair : pas trouver plus de CVE car il y en a déjà bien trop mais décider lesquelles méritent vos deux heures de patch cette semaine. Et c'est précisément ce que les approches existantes n'aident pas à faire.
À quoi ressemble une bonne priorisation
Une priorisation utile ne peut pas reposer sur un seul indicateur. Elle doit produire un score qui se recalcule en continu, en croisant plusieurs catégories de signaux :
- Exploitation active : CISA KEV, rapports de CERT, feeds privés (Shadowserver, Telegram, etc.)
- Disponibilité d'exploits : ExploitDB, Metasploit, PoC GitHub, templates Nuclei
- Probabilité statistique : EPSS, utilisé comme signal complémentaire, jamais seul
- Avis CERT et advisories éditeurs
- Contexte SI : la techno concernée est-elle dans vos assets ?
- Sightings : Est ce que la vulnérabilité est beaucoup mentionnée sur les réseaux sociaux ?
Bien fait, ce score évolue en temps réel : une CVE à 21/100 aujourd'hui peut passer à 60/100 demain si un PoC sort sur GitHub, puis à 95/100 après identification d'une exploitation active. C'est précisément cette dynamique qui manque au CVSS, figé à la publication.
Si ce constat résonne avec votre quotidien : trop de CVE, trop peu de temps, trop peu de signaux pour décider, c'est exactement la question qui nous a poussés à construire SYRN. Vous pouvez l'essayer gratuitement.