2026年11月12日

2026年11月12日

Vérifier les vulnérabilités des extensions WordPress : WP-CLI, WPScan

Cet article est une édition localisée de l'original japonais. Lire l'original en japonais

Pour les vulnérabilités des extensions, le délai entre leur publication et le début des attaques peut être court. La base consiste à répéter régulièrement la démarche suivante : identifier les extensions et versions installées, les comparer avec les vulnérabilités connues, puis mettre à jour s'il existe une version corrigée. Cet article décrit tour à tour la vérification des versions avec WP-CLI, la comparaison avec WPScan, la lecture des bases de vulnérabilités, le contrôle d'une éventuelle altération et la conduite à tenir en cas de faille. Les commandes et les conditions tarifaires ont été vérifiées dans les documentations officielles en novembre 2026.

1. Dresser la liste des extensions et de leurs versions

Commencez par savoir ce qui est installé et dans quelle version. Vous pouvez aussi le voir dans « Extensions » → « Extensions installées » (Plugins → Installed Plugins) de l'administration, mais avec WP-CLI, vous pouvez enregistrer la liste.

# Afficher nom, version, état (actif/inactif) et mise à jour disponible
wp plugin list --fields=name,version,status,update

# Afficher uniquement celles qui ont une mise à jour
wp plugin list --update=available

# Enregistrer en JSON pour garder une trace
wp plugin list --fields=name,version,status --format=json > plugins.json

Les extensions désactivées figurent aussi dans la liste. Même désactivées, leurs fichiers restent sur le serveur et un fichier vulnérable peut être atteint directement : supprimez donc celles que vous n'utilisez pas. Les bases de WP-CLI sont décrites dans « Gérer les extensions avec WP-CLI ».

2. Comparer avec les vulnérabilités connues avec WPScan

WPScan est un outil en ligne de commande qui examine un site WordPress de l'extérieur. Les informations sur les vulnérabilités sont obtenues depuis l'API de WPScan : créez donc un compte sur wpscan.com, générez un jeton d'API et utilisez-le.

Selon la page des tarifs de WPScan, le plan gratuit est limité à un usage non commercial, et les appels à l'API sont limités à 25 par jour. Pour un site professionnel, il faut une licence payante. L'outil fonctionne aussi sans jeton d'API, mais les informations sur les vulnérabilités ne sont alors pas affichées.

# Installation (avec gem de Ruby)
gem install wpscan

# Avec Docker
docker pull wpscanteam/wpscan

# Rechercher les extensions pour lesquelles des vulnérabilités sont signalées
wpscan --url https://example.com --api-token YOUR_API_TOKEN -e vp

# Utiliser à la fois la détection passive et la détection aggressive
wpscan --url https://example.com --api-token YOUR_API_TOKEN -e vp --plugins-detection mixed

Les principales valeurs de -e sont les suivantes.

Valeur Cible
vp Extensions pour lesquelles des vulnérabilités sont signalées
ap Toutes les extensions
p Extensions populaires
vt Thèmes pour lesquels des vulnérabilités sont signalées

Par défaut, la détection des extensions est passive : elle s'appuie sur ce qui se lit dans le HTML des pages, par exemple. Les extensions qui ne laissent pas de trace dans le HTML peuvent ne pas être trouvées ; en indiquant aggressive ou mixed, vous détectez davantage d'extensions, mais le nombre de requêtes augmente aussi.

N'utilisez WPScan que sur un site que vous administrez ou pour lequel vous avez une autorisation. Pour les détails d'utilisation, consultez aussi « Analyser les vulnérabilités d'un site avec WPScan ».

3. Vérifier le détail dans une base de vulnérabilités

Pour une extension dont le nom ressort dans les résultats de WPScan ou dans l'actualité de la sécurité, vérifiez le détail dans les bases de données suivantes.

  • WPScan Vulnerability Database (wpscan.com)
  • Wordfence Intelligence (wordfence.com)
  • Patchstack Database (patchstack.com)
  • NVD (nvd.nist.gov, recherche par numéro CVE)

Voici les éléments à regarder.

Élément Ce qu'il faut vérifier
Versions concernées Votre version se situe-t-elle dans la plage ?
Version corrigée Une mise à jour résout-elle le problème ? Il arrive qu'il n'y ait pas encore de version corrigée
Privilèges requis Exploitable sans connexion, ou faut-il les droits d'un auteur ou d'un abonné ?
Gravité (CVSS) Valeur de 0 à 10. Plus elle est élevée, plus l'impact est grand
Type XSS, injection SQL, élévation de privilèges, téléversement de fichiers arbitraires, etc.

Traitez en premier les failles exploitables sans connexion et celles de gravité élevée. Les failles exploitables avec les droits d'un abonné sont à traiter en urgence sur les sites qui acceptent les inscriptions d'utilisateurs (sites de membres, boutiques, etc.).

4. Vérifier que les fichiers n’ont pas été altérés

Quand une vulnérabilité a pu être exploitée, vérifiez que les fichiers sont tels qu'ils ont été distribués. La commande verify-checksums de WP-CLI compare les fichiers avec les sommes de contrôle publiées par WordPress.org.

# Vérifier toutes les extensions
wp plugin verify-checksums --all

# Vérifier une extension précise
wp plugin verify-checksums contact-form-7

# Vérifier les fichiers du cœur de WordPress
wp core verify-checksums

S'il n'y a aucun problème, un message comme Success: Verified 8 of 8 plugins. s'affiche. S'il y a des fichiers ajoutés ou dont le contenu diffère, leur liste est affichée.

Les extensions payantes qui ne sont pas distribuées par WordPress.org n'ont pas de somme de contrôle et ne peuvent donc pas être vérifiées ainsi. Dans ce cas, téléchargez la même version depuis l'éditeur et comparez les fichiers.

5. Que faire quand une vulnérabilité est trouvée

# S'il existe une version corrigée : mettre à jour
wp plugin update contact-form-7

# S'il n'y a pas de version corrigée : désactiver, puis supprimer si l'extension est inutile
wp plugin deactivate vulnerable-plugin
wp plugin delete vulnerable-plugin

# Avant une mise à jour groupée, vérifier ce qui sera mis à jour
wp plugin update --all --dry-run

vulnerable-plugin est un exemple. Remplacez-le par le slug réel (la colonne name de wp plugin list).

  • Faites une sauvegarde avant la mise à jour, et vérifiez après la mise à jour que les principaux écrans (formulaire de contact, paiement, etc.) fonctionnent.
  • Pour une extension qui n'a pas de version corrigée et dont le développement est arrêté, envisagez de migrer vers une autre extension offrant la même fonction. Pour une extension dont la distribution a été suspendue par WordPress.org, une mention de suspension apparaît sur la page de l'extension.
  • S'il y a des signes d'altération, la mise à jour ne suffit pas. Vérifiez aussi l'ajout d'utilisateurs administrateurs, les fichiers PHP déposés dans uploads et les modifications de wp-config.php, et restaurez depuis une sauvegarde si nécessaire.

6. Faire de la vérification une habitude

  • Dans « Extensions » de l'administration, vous pouvez activer la mise à jour automatique extension par extension (à partir de WordPress 5.5). Activez-la d'abord pour celles dont la mise à jour risque peu de casser l'affichage. Pour en savoir plus, consultez « Configurer la mise à jour automatique des extensions ».
  • Si vous exécutez WPScan régulièrement avec cron, faites attention aux 25 appels par jour du quota gratuit et à la condition d'usage non commercial.
  • L'extension de sécurité Wordfence signale aussi, lors de ses analyses, les extensions qui nécessitent une mise à jour. Son usage est expliqué dans « Analyser le site avec Wordfence ».

Résumé

La vérification des vulnérabilités des extensions se fait dans l'ordre suivant : dresser la liste (wp plugin list), comparer avec les vulnérabilités connues (WPScan ou bases de vulnérabilités), vérifier l'absence d'altération (wp plugin verify-checksums), puis traiter par une mise à jour ou une suppression. Supprimer les extensions inutilisées est la mesure qui demande le moins d'efforts.

Une question sur WordPress ? L'éditeur de ce site est basé au Japon et répond en japonais. Contact (en japonais)

お気軽にご相談ください

お見積りへ お問い合わせへ
▲