CVE signifie Common Vulnerabilities and Exposures et désigne le catalogue de référence mondial des vulnérabilités de sécurité connues publiquement. Le programme est géré par la MITRE Corporation depuis 1999 et financé par la CISA, l'agence américaine de cybersécurité. Chaque vulnérabilité reçoit un identifiant unique au format CVE-ANNÉE-NUMÉRO, comme CVE-2021-44228 pour Log4Shell, afin que les éditeurs, les scanners, les chercheurs et les articles de presse désignent tous la même faille. Les identifiants sont attribués par plusieurs centaines de CVE Numbering Authorities (CNA) dans le monde. La gravité d'une CVE est évaluée avec le Common Vulnerability Scoring System (CVSS), une échelle de 0,0 à 10,0 maintenue par FIRST : à partir de 9,0 la note est Critical, de 7,0 à 8,9 High, de 4,0 à 6,9 Medium et en dessous Low. L'ampleur du système a explosé : plus de 40 000 nouvelles CVE ont été publiées pour la seule année 2024, et dans l'écosystème WordPress un peu moins de 8 000 vulnérabilités ont été divulguées en 2024, dont environ 96 pour cent dans des extensions.
Que signifie CVE ?
Avant l'existence des CVE, chaque éditeur de sécurité décrivait les vulnérabilités avec ses propres mots, et personne ne pouvait dire si le dépassement de tampon d'un avis correspondait au même bug que l'exécution à distance d'un autre. Le programme Common Vulnerabilities and Exposures, lancé par MITRE en 1999, a résolu cela avec quelque chose de trompeusement simple : un nom unique par faille. Une fiche CVE contient cet identifiant, une courte description, des références vers les avis et les correctifs, ainsi que les produits concernés.
Le format de l'identifiant est CVE-ANNÉE-NUMÉRO, où l'année est celle de l'attribution et pas nécessairement celle de la découverte, et où le numéro compte quatre chiffres ou plus. La base officielle se trouve sur cve.org. Par-dessus vient la National Vulnerability Database (NVD), gérée par le NIST, l'institut américain de normalisation, qui enrichit les fiches CVE de scores de gravité, de plages de versions concernées et de classifications de faiblesses. Lorsque votre scanner de sécurité affiche des données de gravité pour une CVE, elles proviennent en général de la NVD.
Comment une vulnérabilité obtient-elle un identifiant CVE ?
Les identifiants CVE sont distribués par les CVE Numbering Authorities, ou CNA en abrégé. Il s'agit d'éditeurs de logiciels, d'entreprises de sécurité et d'organismes de recherche autorisés à attribuer des identifiants pour leurs propres produits ou pour leur domaine de compétence. Le réseau compte désormais plusieurs centaines de CNA dans des dizaines de pays, si bien qu'un chercheur qui découvre une faille dans un produit Cisco, par exemple, la signale directement à Cisco, et Cisco attribue elle-même la CVE.
Le déroulement type ressemble à ceci : un chercheur découvre une vulnérabilité et la signale à la CNA compétente, la CNA réserve un identifiant CVE pendant que le correctif est développé, et une fois le correctif publié la fiche paraît en même temps que l'avis de sécurité. Cette phase de réservation explique pourquoi vous voyez parfois un identifiant CVE mentionné publiquement sans qu'aucun détail n'y soit encore rattaché.
Pour les utilisateurs de WordPress, un détail mérite d'être connu : Wordfence, WPScan et Patchstack sont tous les trois des CNA. La grande majorité des CVE portant sur des extensions et des thèmes WordPress est attribuée par l'un de ces trois acteurs, ce qui explique aussi que leurs bases de vulnérabilités soient les sources les plus complètes pour l'écosystème WordPress.
Qu'est-ce que le score CVSS ?
Un nom seul ne vous dit pas à quel point une faille est grave. C'est le rôle du Common Vulnerability Scoring System, un standard ouvert maintenu par FIRST, l'association mondiale des équipes de réponse à incident. Le CVSS condense les caractéristiques techniques d'une vulnérabilité en un score compris entre 0,0 et 10,0. La version 2 est parue en 2007, la version 3.0 en 2015, l'affinement 3.1 en 2019 et la version 4.0 en novembre 2023. En pratique, la plupart des bases et des avis parlent encore CVSS 3.1, l'adoption de la 4.0 progressant lentement.
Les niveaux de gravité CVSS, de None à Critical
| Niveau | Score CVSS | Signification typique |
|---|---|---|
| None | 0,0 | Aucun impact |
| Low | 0,1 à 3,9 | Difficile à exploiter ou impact très limité |
| Medium | 4,0 à 6,9 | Impact réel, mais soumis à des conditions comme une interaction utilisateur ou des privilèges existants |
| High | 7,0 à 8,9 | Impact sérieux, souvent exposition de données ou élévation de privilèges |
| Critical | 9,0 à 10,0 | Typiquement une exploitation à distance sans authentification avec compromission complète |
Le fameux 9,8 que l'on voit sur tant d'avis est le score signature d'une exécution de code à distance sans authentification : atteignable par le réseau, sans privilèges, sans interaction utilisateur. Un 10,0 parfait sort en plus du composant vulnérable pour atteindre d'autres systèmes, ce qu'a réussi Log4Shell.
Comment un score CVSS est-il calculé ?
Le score de base découle d'une poignée de métriques qui décrivent comment une faille peut être atteinte et ce qu'elle casse. Côté exploitabilité : Attack Vector (réseau, adjacent, local, physique), Attack Complexity, Privileges Required et User Interaction. Côté impact : l'effet sur Confidentiality, Integrity et Availability, plus, en version 3.1, la métrique Scope, qui indique si les dégâts débordent sur d'autres composants. Les choix retenus sont consignés dans une chaîne de vecteur compacte que vous trouverez sur chaque fiche NVD :
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N atteignable par le réseau
AC:L faible complexité d'attaque
PR:N aucun privilège requis
UI:N aucune interaction utilisateur nécessaire
S:U périmètre inchangé
C:H/I:H/A:H impact élevé sur la confidentialité, l'intégrité, la disponibilité
Résultat : score de base 9,8, CriticalL'intérêt du vecteur, c'est qu'il en dit plus long que le chiffre. Un 7,5 avec PR:N et un 7,5 avec PR:H sont deux bêtes très différentes pour votre modèle de menace, et lire le vecteur prend dix secondes une fois les abréviations connues.
Quelles sont les nouveautés du CVSS 4.0 ?
La version 4.0 répond aux principales critiques adressées à la 3.1. La métrique Scope, source de confusion, disparaît au profit de niveaux d'impact distincts pour le système vulnérable et pour les systèmes en aval. User Interaction gagne en nuance avec des variantes passive et active, et une nouvelle métrique Attack Requirements décrit les conditions qui doivent exister sur la cible. Les anciennes métriques temporelles ont été retravaillées en métriques de menace, et le standard nomme désormais explicitement ses déclinaisons de score : CVSS-B pour le score de base pur, CVSS-BT avec les données de menace et CVSS-BE avec le contexte environnemental. Sur le plan conceptuel, tout cela est une amélioration. En pratique, l'écosystème bouge lentement : attendez-vous à lire des vecteurs 3.1 pendant encore des années.
Pourquoi un score CVSS élevé n'est pas automatiquement votre plus grand risque
Voici la vérité inconfortable au sujet du CVSS : il mesure la gravité, pas la probabilité. L'immense majorité des CVE publiées ne sont jamais exploitées dans la nature, tandis que certaines failles notées Medium sont martelées en quelques heures parce qu'un exploit est public et que la cible est partout. Deux jeux de données aident à combler cet écart. Le score EPSS, également issu de FIRST, estime la probabilité qu'une vulnérabilité soit exploitée dans les 30 jours à venir à partir de télémétries réelles. Et le catalogue CISA KEV recense les vulnérabilités dont l'exploitation est confirmée, ce qui constitue le signal le plus fort disponible.
Une règle de priorisation utile pour un propriétaire de site : corrigez d'abord ce qui figure dans le KEV ou affiche un score EPSS élevé et se trouve dans un composant exposé sur Internet. Un 9,8 dans une extension que vous avez désactivée l'an dernier compte moins qu'un 7,5 dans l'extension de formulaire de contact que tous vos visiteurs peuvent atteindre. La gravité est affaire de contexte, et vous seul connaissez le vôtre.
Les CVE dans l'écosystème WordPress
Le cœur de WordPress est aujourd'hui une cible difficile et représente nettement moins d'un pour cent des vulnérabilités divulguées. L'action se joue dans l'écosystème des extensions : selon Patchstack, un peu moins de 8 000 nouvelles vulnérabilités ont été divulguées dans l'écosystème WordPress en 2024, dont environ 96 pour cent dans des extensions et la plus grande partie du reste dans des thèmes. Les catégories les plus fréquentes sont le cross-site scripting, le cross-site request forgery et les contrôles d'accès défaillants. Rien de tout cela ne signifie que WordPress est peu sûr : cela signifie que la sécurité de votre site se décide au choix des extensions que vous installez et à la vitesse à laquelle vous les mettez à jour. Une extension installée sur 100 000 sites avec une faille connue non corrigée devient une cible de balayage de masse en quelques jours, parfois en quelques heures.
Exemples de CVE célèbres
- CVE-2014-0160, Heartbleed : divulgation de mémoire dans OpenSSL qui permettait aux attaquants de lire des clés privées sur les serveurs. Le bug qui a donné aux vulnérabilités des logos et des noms.
- CVE-2017-0144, EternalBlue : la faille SMB à l'origine de la vague de rançongiciels WannaCry en 2017.
- CVE-2021-44228, Log4Shell : un CVSS 10,0 dans la bibliothèque de journalisation Java Log4j. Une chaîne de caractères forgée dans n'importe quel champ journalisé menait à l'exécution de code à distance, et la moitié d'Internet journalisait les saisies utilisateur.
- CVE-2023-4966, Citrix Bleed : fuite de jetons de session dans Citrix NetScaler, exploitée par des groupes de rançongiciels contre des milliers d'équipements.
Comment InspectWP exploite-t-il les données CVE ?
InspectWP détecte les extensions et les thèmes d'un site WordPress analysé et les compare aux données de vulnérabilités connues : un rapport peut ainsi vous indiquer qu'un composant installé précis fait l'objet d'une CVE publiée, quelle en est la gravité et qu'une mise à jour est disponible. Cela comble l'agaçant fossé entre une CVE qui existe quelque part dans une base et le moment où vous apprenez qu'elle concerne l'un de vos sites. Associé aux rapports automatiques planifiés, vous obtenez la version pratique de la gestion des vulnérabilités pour WordPress : savoir ce que vous faites tourner, savoir ce qui est cassé, et mettre à jour en priorité ce qui compte.