# Lire un avis de vulnérabilité WordPress et évaluer son exposition réelle

> Un CVSS de 9,8 ne veut pas dire panique immédiate sur tous vos sites. Voici comment lire un avis de vulnérabilité pour savoir ce qui vous concerne vraiment.

- Auteur : Clément Hadrot
- Publié le : 2024-03-29
- Mis à jour le : 2024-03-29
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/lire-avis-vulnerabilite-wordpress-cve-cvss-exposition-reelle/

## L’essentiel

- Le score CVSS mesure la gravité théorique, pas votre exposition
- Les prérequis d'exploitation changent tout
- Les versions affectées se vérifient précisément

Un lundi matin, une alerte tombe : une extension installée sur douze sites clients vient de recevoir un correctif de sécurité classé critique, CVSS 9,8. Le réflexe de panique consisterait à tout mettre à jour dans l'heure, en urgence, sans vérifier le contexte. Un réflexe plus utile consiste à passer trois minutes à lire l'avis en détail, car ce score de 9,8 peut concerner une configuration que vous n'utilisez sur aucun de vos douze sites.

Savoir lire un avis de vulnérabilité correctement, au-delà du score affiché en gros caractères, est une compétence qui change directement la priorisation des mises à jour dans une équipe qui gère plusieurs sites en parallèle. Voici la méthode que nous appliquons à chaque alerte reçue.

## Ce que représente réellement le score CVSS

Le Common Vulnerability Scoring System note une vulnérabilité de 0 à 10 selon plusieurs critères combinés : la complexité d'exploitation, les privilèges requis pour l'attaquant, l'interaction utilisateur nécessaire, et l'impact sur la confidentialité, l'intégrité et la disponibilité. Un score élevé signifie que la faille est grave *dans l'absolu*, pas qu'elle est automatiquement exploitable sur votre configuration précise.

Deux vulnérabilités notées 9,8 peuvent avoir des profils d'exposition radicalement différents : l'une exploitable par n'importe quel visiteur anonyme sans compte, l'autre nécessitant déjà un accès administrateur au site, ce qui réduit fortement le scénario réaliste d'attaque puisqu'un attaquant disposant déjà de ce niveau d'accès a généralement des moyens plus directs de nuire.

## Les prérequis d'exploitation, la vraie question à se poser

> L'essentiel à retenir : Le score CVSS mesure la gravité théorique, pas votre exposition ; Les prérequis d'exploitation changent tout ; Les versions affectées se vérifient précisément

Chaque avis de vulnérabilité sérieux détaille les prérequis nécessaires à l'exploitation. C'est cette section, plus que le score global, qui détermine votre priorité réelle :

- **Niveau d'accès requis** : « non authentifié » signifie exploitable par n'importe qui, à traiter en urgence. « Abonné » ou « contributeur » réduit le risque aux sites qui ouvrent l'inscription publique. « Administrateur » réduit fortement le scénario réaliste.
- **Configuration spécifique nécessaire** : certaines failles ne s'activent que si une option précise de l'extension est cochée, ou si un module additionnel payant est installé.
- **Interaction utilisateur requise** : une faille XSS qui nécessite qu'un administrateur clique sur un lien piégé n'a pas le même profil de risque qu'une faille exploitable sans aucune action humaine.

## Vérifier précisément les versions affectées

Un avis de vulnérabilité mentionne toujours une plage de versions touchées, par exemple « affecte les versions jusqu'à 3.4.1 incluse, corrigée en 3.4.2 ». Cette information doit être confrontée à la version réellement installée sur chacun de vos sites, pas supposée. Une commande WP-CLI permet de vérifier rapidement :

```
wp plugin list --format=json | grep -A2 "nom-extension"
```

Sur un parc de plusieurs sites, un script qui interroge chaque installation via WP-CLI et compare la version installée à la plage affectée permet de cibler exactement les sites concernés, plutôt que de mettre à jour l'extension partout par précaution, ce qui peut introduire des régressions inutiles sur des sites non exposés.

## Le type de vulnérabilité change aussi la priorité

| Type de faille | Niveau de priorité typique |
| --- | --- |
| Injection SQL non authentifiée | Urgence absolue, correctif sous 24 heures |
| Exécution de code à distance | Urgence absolue, correctif sous 24 heures |
| XSS stockée non authentifiée | Haute priorité, correctif sous 48 à 72 heures |
| CSRF nécessitant une action admin | Priorité modérée, planifiable sous une semaine |
| Divulgation d'information mineure | Priorité basse, à traiter lors de la prochaine fenêtre de maintenance |

## Où trouver des avis fiables et détaillés

Les bases de données spécialisées WordPress (WPScan, Patchstack) offrent en général davantage de détail sur les prérequis d'exploitation que le simple changelog de l'extension, qui se contente souvent d'un vague « amélioration de la sécurité ». Croiser les deux sources, l'annonce officielle de l'éditeur et l'avis détaillé d'une base de vulnérabilités, donne une vision plus complète que l'une ou l'autre isolément.

## Construire sa propre grille de décision

Sur nos sites, chaque alerte de vulnérabilité passe par trois questions avant de déterminer le délai de traitement : le site concerné ouvre-t-il l'inscription publique ou l'accès contributeur, la fonctionnalité vulnérable est-elle réellement utilisée sur ce site, et un contournement temporaire existe-t-il (désactivation d'une fonctionnalité précise) en attendant une mise à jour testée.

> Une alerte critique sur une extension de paiement, jamais activée sur un des sites de notre parc mais toujours installée « au cas où », nous a appris à désinstaller systématiquement ce qui n'est pas utilisé plutôt que de le laisser inactif : une extension désactivée reste une surface d'attaque potentielle si elle n'est pas totalement supprimée.

## En résumé

Un score CVSS élevé mérite l'attention mais ne dispense jamais de lire les prérequis d'exploitation et de vérifier les versions réellement installées sur vos sites. Cette lecture méthodique transforme une réaction de panique généralisée en une priorisation ciblée, plus rapide à exécuter et plus fiable sur un parc de plusieurs sites gérés en parallèle.