Avant l’existence des CVE, chaque éditeur, chaque antivirus et chaque bulletin de sécurité donnait son propre nom à une même faille, ce qui rendait les comparaisons presque impossibles. Le programme CVE a pour mission d’identifier, de définir et de cataloguer les vulnérabilités de cybersécurité rendues publiques, avec un seul enregistrement par faille. Une CVE n’est donc pas une note de gravité ni une preuve d’exploitation : c’est un nom commun, que tout le monde peut citer.
Comment lire un identifiant CVE
Un identifiant se compose du préfixe CVE, d’une année et d’un numéro, par exemple CVE-2024-4577 (la faille PHP-CGI sous Windows) ou CVE-2023-3460 (une faille de l’extension Ultimate Member). L’année correspond en général au moment où l’identifiant a été réservé, pas forcément à celui où la faille a été introduite dans le code. Le numéro n’a pas de signification particulière et sa longueur varie.
Chaque enregistrement contient une description, les produits et versions touchés, des références (avis de l’éditeur, analyse du chercheur) et, souvent, un score CVSS qui estime la gravité ainsi qu’un type de faiblesse (CWE).
Qui attribue les CVE
Le programme est sponsorisé par l’agence américaine CISA. Les identifiants ne sont pas tous délivrés par un organisme central : ils sont attribués par des CNA (CVE Numbering Authorities), des organisations partenaires autorisées à numéroter les failles de leur périmètre. L’équipe de PHP a ainsi attribué CVE-2024-4577. Pour WordPress, plusieurs acteurs de la sécurité sont CNA, dont Wordfence, WPScan et Patchstack : ce sont eux qui publient la majorité des CVE d’extensions et de thèmes.
Un enregistrement passe par plusieurs états. Il est d’abord réservé (RESERVED) pendant la correction, sans détail public, puis publié (PUBLISHED). Pour CVE-2024-4577, la réservation date du 6 mai 2024 et la publication du 9 juin 2024. Un identifiant attribué par erreur ou en double peut aussi être rejeté.
CVE, NVD, KEV : qui fait quoi
- CVE : le catalogue des identifiants et des descriptions.
- NVD (National Vulnerability Database, NIST) : une base qui enrichit les CVE avec des scores CVSS, des catégories CWE et la liste des produits concernés. Son traitement a pris du retard depuis 2024, d’où l’intérêt des bases spécialisées.
- KEV (CISA) : le catalogue des CVE dont l’exploitation réelle est prouvée, utile pour décider quoi corriger en premier.
Pour WordPress : utiliser les CVE au quotidien
Pour un propriétaire de site, l’intérêt d’une CVE est de relier une alerte à une version précise : « extension X jusqu’à la version 2.6.6 incluse, corrigée en 2.6.7 ». Il suffit alors de comparer avec la version installée. Les outils de surveillance le font automatiquement ; les alertes de vulnérabilités de WP Masquerade Pro, par exemple, vérifient chaque jour les extensions, thèmes et la version de WordPress installés, avec gravité et version corrigée. Le choix des sources et l’organisation de la veille sont détaillés dans ce guide de surveillance.
Le cœur de WordPress reçoit lui aussi des CVE, généralement corrigées par des versions mineures appliquées automatiquement : l’historique des correctifs du cœur depuis 2020 en donne un aperçu. Côté serveur, une CVE peut concerner PHP lui-même, comme la faille PHP-CGI de 2024, et c’est alors l’hébergeur qui doit agir.
Erreurs fréquentes
- Penser que « pas de CVE » signifie « pas de faille » : beaucoup de failles d’extensions premium ou peu diffusées ne reçoivent jamais d’identifiant, et une faille zero-day n’en a pas encore.
- Confondre CVE et gravité : l’identifiant ne dit rien du danger, c’est le score et le contexte qui comptent.
- Se fier à une seule base : les délais de publication et la couverture varient d’une source à l’autre.