CVE
Un CVE est l'identifiant public et unique attribué à une faille de sécurité connue, sous la forme CVE suivie de l'année et d'un numéro.
Définition
Un CVE est l’identifiant public et unique attribué à une faille de sécurité connue, sous la forme CVE suivie de l’année et d’un numéro. Il sert de nom commun entre l’éditeur, l’hébergeur, l’outil de scan et le prestataire de maintenance, pour que tous parlent de la même faille sans ambiguïté.
Comment se lit un identifiant CVE ?
Trois blocs séparés par des tirets : le sigle, l’année, le numéro de série.
Le sigle abrège Common Vulnerabilities and Exposures, la liste publique des vulnérabilités et expositions connues. CVE-2024-4577 se lit ainsi : une faille enregistrée en 2024, portant le numéro 4577. L’année est celle de l’attribution du numéro, pas forcément celle de la découverte ni celle de la publication. Le numéro n’a aucun sens caché : il ne classe rien, il numérote.
L’identifiant est attribué par une autorité de numérotation, et l’éditeur du logiciel est très souvent la sienne. Sur l’exemple ci-dessus, c’est le PHP Group qui a rédigé et publié la fiche de sa propre faille. C’est plutôt bon signe : cela veut dire que l’éditeur a reconnu le problème, l’a documenté et, dans le même mouvement, publié le correctif.
Le numéro ne dit pas la gravité
La gravité vient d’un score séparé, le CVSS, noté de 0 à 10.
Le CVSS est publié par le FIRST et calculé à partir de critères objectifs : la faille s’exploite-t-elle à distance, faut-il un compte, faut-il une action de l’utilisateur, que perd-on en confidentialité, en intégrité et en disponibilité. La faille PHP citée plus haut est notée 9,8 sur 10, dans la tranche critique. Un même identifiant peut recevoir des scores différents selon l’organisme qui le calcule, ce qui n’est pas une contradiction mais une question de contexte. Reste à savoir si la faille a été exploitée avant l’application du correctif, ce que seul un examen du site permet d’établir.
Une seconde liste mérite d’être connue, celle des vulnérabilités activement exploitées, tenue par l’agence américaine de cybersécurité. Y figurer change tout : cela signifie que la faille n’est plus théorique, qu’elle est utilisée en ce moment. La faille PHP y a été ajoutée trois jours après sa publication, avec la mention d’un usage avéré par des rançongiciels.
Un CVE critique ne veut pas dire que vous êtes concerné. Chaque fiche décrit des conditions : un système d’exploitation, un mode d’exécution, une plage de versions. Hors de ces conditions, la faille ne s’applique pas. Lire le score sans lire les conditions mène à paniquer pour rien, ou pire, à négliger une faille moins bien notée qui, elle, vous touche.
CVE, CWE : nommer un cas ou nommer une famille
Le CVE désigne une faille précise, le CWE désigne le type de défaut qui l’a produite.
Le CWE est présenté par ses responsables comme une liste, développée par la communauté, des faiblesses courantes du logiciel et du matériel. Une faiblesse y est définie comme une condition qui, dans certaines circonstances, peut contribuer à l’introduction de vulnérabilités. Autrement dit, le CWE décrit une cause récurrente, indépendamment de tout logiciel : mauvaise vérification d’une entrée, mot de passe stocké en clair, contrôle d’accès absent.
La faille PHP prise en exemple porte le CWE-78, l’injection de commande système. Les deux identifiants disent des choses différentes et complémentaires. Le CVE dit : cette version de ce logiciel, dans ces conditions. Le CWE dit : voici la nature du défaut, et voici ce qu’il faut savoir éviter la prochaine fois. Pour un site en production, seul le premier décide d’une action ; le second intéresse celui qui écrit le code.
Deux endroits font référence pour retrouver une fiche : le registre du CVE Program, où l’autorité de numérotation dépose sa description, et la base nationale américaine des vulnérabilités, qui reprend la même référence. Les deux se cherchent directement par l’identifiant, sans passer par un moteur de recherche ni par l’article de blog qui l’aura recopié en le déformant.
Où les CVE touchent un site WordPress
Quatre couches, et ce n’est presque jamais celle qu’on redoute.
Le cœur de WordPress est audité, corrigé vite et mis à jour automatiquement pour les versions de sécurité. Les extensions et les thèmes sont une tout autre affaire : ils viennent de milliers d’auteurs, avec des rythmes de maintenance très inégaux, et c’est là que se concentre l’essentiel des publications. Vient ensuite la version de PHP installée sur l’hébergement, dont le site dépend sans la choisir vraiment. Une extension nulled, enfin, cumule les deux risques : elle ne reçoit aucune mise à jour et contient parfois son propre code ajouté.
La conséquence pratique est simple. Surveiller les CVE de WordPress lui-même sert peu. Ce qui compte, c’est l’inventaire de ce que vous avez réellement installé, avec les numéros de version en face, tenu à jour. C’est exactement l’objet d’un contrat de maintenance.
Que faire quand un CVE sort sur un composant que vous utilisez
Quatre gestes, dans cet ordre, et le premier n’est pas la mise à jour.
Relever la version installée
Pas celle de la documentation, pas celle que vous croyez avoir : celle que le site fait tourner, extension par extension, thème compris, plus la version de PHP.
Comparer à la plage affectée
La fiche du CVE donne les versions concernées et celle qui corrige. Si votre version est en dehors, le dossier s’arrête là et se note.
Mettre à jour, en préproduction d’abord
Une mise à jour de sécurité se passe presque toujours bien, presque n’est pas toujours. Un site qui rapporte de l’argent se teste sur une préproduction avant.
Vérifier après coup
Contrôler la version servie, puis les pages sensibles du site. Une mise à jour appliquée n’est pas une mise à jour réussie tant que personne n’a regardé.
Ce que cela donne sur un site réel
Mesure du 8 septembre 2026, sur quatorze heures de journaux d’un site vitrine WordPress. Entre 0 h 11 et 14 h 15, 114 requêtes visent des adresses du type /php-cgi/php-cgi.exe, réparties sur 9 chemins différents et venues de 4 machines, dont trois hébergées chez le même fournisseur de cloud. Toutes portent la même charge utile, envoyée en POST, qui cherche à faire lire au serveur le contenu de la requête comme du code. Le caractère employé pour le déclencher n’est pas un tiret ordinaire mais un tiret conditionnel, ce qui suffit à identifier la faille visée : celle publiée par le PHP Group en juin 2024. Or cette faille ne concerne que les serveurs Windows exécutant PHP en mode CGI derrière Apache, avec certaines pages de code. Le site visé tourne sous Linux, en PHP 8.3.33, soit bien au-dessus de la version corrective. Le balayage ne peut rien produire ici, et il repasse tous les jours. C’est la démonstration la plus courte de la règle : un identifiant de faille se lit avec ses conditions, système et version comprises, avant de décider si l’on est concerné.
Questions fréquentes
Un CVE sur une de mes extensions veut-il dire que mon site est piraté ?
Non. Il signale qu’une faille est publiquement connue sur ce composant, dans certaines versions. Tant que la vôtre est corrigée ou hors plage, il ne se passe rien. Le risque commence quand la version reste ancienne pendant des semaines après la publication.
Où voir les CVE qui concernent mon site ?
Le plus simple est de partir de l’inventaire du site, pas des listes générales. Un outil de veille qui connaît vos extensions et leurs versions vous alerte utilement ; une liste mondiale de failles, non.
Faut-il tout mettre à jour dès qu’un CVE est publié ?
Pour une faille de sécurité, oui, et vite. La fenêtre entre la publication et les premières exploitations automatisées se compte en jours. Le test en préproduction reste la bonne pratique, il ne doit pas devenir un motif de report.
Que veut dire une faille inscrite sur la liste des vulnérabilités exploitées ?
Que des attaques réelles ont été observées, pas seulement une preuve de concept. C’est le signal le plus fort qui existe pour prioriser, plus utile encore que le score de gravité.
Sources
- CVE Program, fiche CVE-2024-4577 publiée par le PHP Group
- NVD, fiche de la vulnérabilité prise en exemple
- CWE, présentation du référentiel des faiblesses logicielles
- FIRST, spécification CVSS version 3.1
- CISA, catalogue des vulnérabilités activement exploitées
- PHP, journal des versions 8
- WordPress.org, politique de sécurité du projet
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.