Tendances de publication des CVE

47 802 enregistrements CVE ont été publiés en 2025, soit 20 % de plus que l'année précédente. 2026 a déjà atteint 88 746 alors qu'il reste encore des mois.

Le volume a augmenté chaque année depuis la création du CVE Program, mais le rythme de croissance a fortement changé en 2026. Utilisez le graphique ci-dessus pour voir la tendance par mois, trimestre ou année.

Sur cette page. Le graphique et les chiffres ci-dessus sont des statistiques CVE recalculées chaque jour à partir du dépôt cvelistV5 du CVE Program, la source même à partir de laquelle publie le CVE Program.

Elles couvrent le volume de publication par gravité CVSS, par organisation d'attribution et par semaine, mois, trimestre ou année, ainsi que les enregistrements critiques les plus récents. Pour le détail d'une vulnérabilité, suivez n'importe quel identifiant jusqu'à cve.org.

Trois phénomènes se produisent en même temps, et les enregistrements publiés ne permettent pas de les distinguer.

Davantage d'organisations peuvent désormais attribuer des identifiants CVE : des vulnérabilités qui n'étaient jamais enregistrées le sont donc maintenant. La découverte de vulnérabilités automatisée et assistée par l'IA a augmenté ce qu'un seul chercheur peut trouver. Et le programme d'enrichissement de la CISA a complété les enregistrements anciens, ce qui modifie les chiffres historiques après coup.

La hausse du nombre de CVE ne prouve donc pas à elle seule que les logiciels deviennent moins sûrs.

Une CNA est une organisation autorisée à attribuer des identifiants CVE et à publier des enregistrements dans son propre périmètre, généralement ses propres produits. 497 CNA figurent dans ce jeu de données.

Des éditeurs, des projets open source, des plateformes de bug bounty et des CERT nationaux jouent tous ce rôle. La plus importante ici est mitre, avec 39 586 enregistrements. Comme un changement de processus chez une seule CNA peut faire bouger sensiblement les totaux, le graphique permet de filtrer sur une organisation à la fois.

CVSS note une vulnérabilité de 0,0 à 10,0 et la classe par tranches : Faible (0,1-3,9), Moyenne (4,0-6,9), Élevée (7,0-8,9) et Critique (9,0-10,0).

Le score décrit des caractéristiques techniques intrinsèques, comme la façon dont la vulnérabilité est atteinte et ce qu'elle compromet. Il ne mesure pas le niveau de risque d'une organisation donnée.

18.0% des enregistrements publiés depuis 2020 n'ont aucun score CVSS, ni dans les données de la CNA ni dans l'enrichissement de la CISA.

Le score n'a pas été obligatoire pendant la majeure partie de l'histoire du CVE Program. La couverture s'améliore fortement à partir de 2023 et elle est aujourd'hui quasi universelle : le recul de la bande Inconnue sur le graphique reflète donc un changement de pratique de signalement, et non un changement dans les vulnérabilités elles-mêmes. Toute analyse qui ignore les enregistrements sans score sous-estimera les années anciennes.

Une vulnérabilité est une faille dans un logiciel. Une CVE est un identifiant public attribué à une occurrence précise et divulguée de cette faille.

La plupart des vulnérabilités ne reçoivent jamais de CVE : elles sont trouvées et corrigées en interne, ou elles n'entrent dans le périmètre d'aucune CNA. Le nombre de CVE mesure donc l'activité de divulgation, et non la quantité réelle de failles existantes.

Chaque chiffre provient du dépôt officiel cvelistV5 du CVE Program, à partir de l'instantané pris le 31 oct. 2026 UTC.

Les enregistrements sont comptés par date de publication et non par l'année figurant dans l'identifiant CVE, car environ un cinquième des enregistrements sont publiés une autre année que celle indiquée par leur identifiant. Les enregistrements rejetés et retirés sont exclus.

Pas à lui seul. Une vulnérabilité critique dans un composant que vous livrez mais n'appelez jamais peut être moins urgente qu'une vulnérabilité moyenne sur votre API publique.

Pour bien prioriser, il faut savoir si le composant touché est présent dans votre logiciel, si le code vulnérable est atteignable et si la vulnérabilité est exploitée. CVSS ne répond à aucune de ces questions.

Le CRA impose aux fabricants de traiter les vulnérabilités pendant toute la durée de vie prise en charge d'un produit, de signaler les vulnérabilités activement exploitées à l'ENISA dans les 24 heures après en avoir pris connaissance et de tenir à jour la documentation technique.

Ces obligations augmentent avec le volume de ce graphique. Trier manuellement des dizaines de milliers de nouveaux enregistrements par an par rapport à votre propre logiciel n'est pas réaliste : c'est pourquoi le CRA suppose de fait une SBOM et un processus de rapprochement automatisé.

Il vous faut un inventaire exact de ce que contient votre logiciel, puis un rapprochement continu de cet inventaire avec le flux CVE.

CRACI génère une SBOM à partir de votre build, la rapproche des nouveaux enregistrements CVE à mesure de leur publication et n'affiche que les avis qui atteignent le code que vous livrez réellement, ainsi que la documentation que le CRA vous demande de conserver.

Découvrez comment le suivi des vulnérabilités fonctionne en pratique.