Plugins WordPress vulnérables : détecter, prioriser et corriger les failles

Plugins WordPress vulnérables : détecter, prioriser et corriger les failles

La grande majorité des vulnérabilités WordPress ne viennent pas du cœur du CMS mais des plugins installés sur vos sites clients. Identifier lesquels sont exposés, évaluer leur criticité et décider si vous mettez à jour, désactivez ou remplacez — c'est la routine de toute agence qui maintient un parc WordPress.

Ce guide couvre le workflow complet : détection avec les outils courants, lecture d'un score CVSS, triage décisionnel et, pour aller plus loin, automatisation de la veille avec un script de notification webhook — un angle que la plupart des guides francophones ne couvrent pas.

1. Pourquoi les plugins sont le maillon faible
2. Détecter les plugins vulnérables dans votre parc
3. Lire un score CVSS
4. Triage : mettre à jour, désactiver ou remplacer
5. Automatiser la veille CVE WordPress

Pourquoi les plugins sont le maillon faible

Le cœur de WordPress est maintenu par une équipe dédiée et corrigé de façon centralisée. Les plugins dépendent de développeurs indépendants dont l'activité et la rigueur varient considérablement. C'est là que se concentrent les vulnérabilités publiées chaque semaine.

Deux situations aggravent structurellement le risque pour votre parc :

• Les plugins abandonnés. Un plugin retiré du répertoire WordPress.org cesse de recevoir des correctifs. Il reste installé sur des centaines ou des milliers de sites, exposé à toute vulnérabilité découverte après sa mise en arrêt. WordPress.org retire régulièrement des extensions du répertoire sans notifier les sites qui les ont installées.
• La supply chain. Certains plugins peu actifs sont rachetés par des tiers qui y introduisent du code malveillant. L'URL officielle du plugin change de propriétaire sans que les sites installés reçoivent le moindre avertissement. Les mises à jour automatiques peuvent dans ce cas livrer un plugin compromis.

Pour votre agence, le risque est double : technique (site compromis, données client exfiltrées) et contractuel (responsabilité si une mise à jour urgente documentée a été ignorée). Une vulnérabilité exploitée sur un site client que vous maintenez engage votre crédibilité, quelle que soit l'origine du plugin.

Détecter les plugins vulnérables dans votre parc

Plusieurs outils croisent vos versions installées avec des bases de vulnérabilités publiques. Chacun a un périmètre et un mode d'accès différents. Le bon choix dépend de votre infrastructure et de la taille de votre parc.

WPScan

WPScan est l'outil de référence. Il interroge la base de vulnérabilités WPScan, dont les données sont vérifiées manuellement par des chercheurs en sécurité. WPScan est également une autorité d'attribution de CVE (CNA), ce qui lui permet d'assigner directement des identifiants CVE pour WordPress, ses plugins et ses thèmes.

Usage basique depuis une machine avec accès réseau au site :

wpscan --url https://exemple.fr --enumerate p --plugins-detection aggressive --api-token VOTRE_TOKEN

Le token API est gratuit pour un usage personnel limité. Les offres payantes conviennent à un usage en production sur plusieurs dizaines de sites.

WP-CLI audit

Si vous avez un accès SSH au serveur, WP-CLI liste les extensions avec leur version sans aucun plugin tiers. Couplé à un appel à l'API WPVulnerability, vous obtenez un rapport en quelques secondes :

wp plugin list --format=json | jq '.[] | {name, version}'

WP-CLI est particulièrement utile pour des vérifications ponctuelles avant un déploiement ou dans un pipeline CI/CD. Sur les serveurs mutualisés sans accès SSH, cette option n'est pas disponible.

Wordfence et Patchstack

Wordfence est l'un des scanners les plus déployés sur WordPress. Son scanner signale les extensions abandonnées ou retirées du répertoire, en plus des vulnérabilités connues. Patchstack propose une détection gratuite avec alerte par e-mail par plugin et une fonctionnalité de virtual patching — blocage automatique d'une faille sans mise à jour du plugin — dans son offre payante.

Sentinelo Scan

Si vous préférez une vérification sans agent installé sur le serveur client, l'outil de scan Sentinelo exécute 19 contrôles de sécurité sur un site WordPress et croise les résultats avec la base WPScan. L'accès est gratuit dans un quota horaire, sans inscription. Il couvre aussi la validité du certificat SSL, la réputation externe et d'autres points de contrôle utiles pour un premier état des lieux.

Lire un score CVSS : ce qui est critique vs ce qui peut attendre

Le score CVSS (Common Vulnerability Scoring System) va de 0 à 10. Il est calculé à partir de plusieurs vecteurs : mode d'accès (réseau ou local), complexité d'exploitation, niveau de privilèges requis, interaction utilisateur nécessaire, impact sur la confidentialité, l'intégrité et la disponibilité des données.

Score CVSS	Sévérité	Action recommandée
9,0 – 10,0	Critique	Mise à jour ou désactivation dans l'heure
7,0 – 8,9	Élevée	Mise à jour dans les 24 heures
4,0 – 6,9	Moyenne	Prochaine fenêtre de maintenance planifiée
0,1 – 3,9	Faible	Cycle mensuel habituel

Un vecteur réseau sans authentification requise (AV:N/AC:L/PR:N/UI:N) indique une faille exploitable à distance par n'importe qui sans compte sur le site : c'est le cas le plus urgent, quelle que soit la sévérité affichée. À l'inverse, une faille locale (AV:L) ou nécessitant un rôle administrateur (PR:H) demande un accès préalable et peut attendre la prochaine maintenance.

Le score brut ne suffit pas : prenez aussi en compte si un exploit public est disponible. WPScan et Patchstack signalent explicitement les failles pour lesquelles un code d'exploitation circule déjà — ce qui fait passer toute vulnérabilité, même de sévérité moyenne, au niveau d'urgence maximale.

Triage : mettre à jour, désactiver ou remplacer

Une fois le plugin vulnérable identifié et son score évalué, la décision suit trois chemins possibles :

1. Mise à jour immédiate. Un correctif est disponible et le plugin est actif. Appliquez la mise à jour après vérification qu'une sauvegarde récente existe. La plateforme de mises à jour Sentinelo applique les mises à jour WordPress, WooCommerce et les extensions automatiquement, après confirmation qu'une sauvegarde de moins de 24 heures est disponible — avec retour automatique du composant si le site cesse de répondre après la mise à jour.
2. Désactivation préventive. Pas de correctif disponible et la vulnérabilité est critique ou élevée. Désactivez le plugin immédiatement et informez le client. Un plugin désactivé ne s'exécute plus, mais ses fichiers restent sur le serveur et peuvent être réactivés par erreur — supprimez-les.
3. Remplacement. Le plugin est abandonné (retiré du répertoire, sans mise à jour depuis plus d'un an, sans mainteneur actif déclaré). Cherchez un équivalent activement maintenu et planifiez la migration avec le client lors de la prochaine intervention.

Communiquer avec le client sans générer d'anxiété inutile

Formulez la communication avec précision, sans alarmisme : citez le plugin concerné, le numéro CVE si disponible, la version corrigée et l'action que vous avez effectuée. Exemple : « Le plugin X installé sur votre site présentait une vulnérabilité documentée (CVE-XXXX-YYYY, score CVSS X,X). Nous l'avons mis à jour vers la version Z.Z.Z qui la corrige. Aucune action de votre part n'est requise. »

Si le plugin a dû être désactivé sans alternative immédiate, précisez la fonctionnalité impactée, les conditions dans lesquelles elle l'est et le délai estimé pour proposer un remplacement.

Automatiser la veille CVE WordPress

La veille manuelle ne tient pas à l'échelle d'un parc de 20, 50 ou 100 sites. L'objectif est d'être notifié automatiquement dès qu'une CVE concerne un plugin présent dans votre parc — avant que vos clients ne le découvrent ailleurs.

Sources à brancher

• WPScan API — base vérifiée manuellement, accessible par token API, interrogeable par plugin ou par version.
• Patchstack Alliance — flux RSS et alertes e-mail configurables par plugin spécifique, avec signal sur les failles sans correctif disponible.
• NVD (National Vulnerability Database, NIST) — référence officielle, recherchable par mot-clé wordpress, utile pour les failles publiées avant leur intégration dans les bases spécialisées.

Script bash : notification webhook sur nouvelle CVE

Le script ci-dessous interroge l'API WPScan pour un plugin donné et envoie une notification vers un webhook (Slack, Teams, Discord ou tout endpoint HTTP) si une CVE jusqu'ici inconnue est détectée. Stockez les tokens dans un fichier d'environnement protégé, jamais en dur dans le script.

#!/usr/bin/env bash
set -euo pipefail

PLUGIN="contact-form-7"
API_TOKEN="${WPSCAN_API_TOKEN}"
WEBHOOK_URL="${SLACK_WEBHOOK_URL}"
STATE_FILE="/var/lib/cve-watch/${PLUGIN}.seen"

mkdir -p "$(dirname "$STATE_FILE")"
touch "$STATE_FILE"

response=$(curl -s \
  -H "Authorization: Token token=${API_TOKEN}" \
  "https://wpscan.com/api/v3/plugins/${PLUGIN}")

# Extraire les CVE non encore vues
new_cves=$(echo "$response" \
  | jq -r '.vulnerabilities[].references.cve[]? // empty' \
  | grep -vxFf "$STATE_FILE" || true)

if [ -n "$new_cves" ]; then
  echo "$new_cves" >> "$STATE_FILE"
  payload=$(printf '{"text":"Nouvelle CVE détectée pour *%s* : %s"}' \
    "$PLUGIN" "$(echo "$new_cves" | tr '\n' ' ')")
  curl -s -X POST -H 'Content-type: application/json' \
    --data "$payload" "$WEBHOOK_URL"
fi

Déployez ce script sur votre serveur de maintenance avec un cron par plugin critique. Le fichier .seen évite les notifications en doublon entre deux exécutions. Adaptez PLUGIN à chaque extension à surveiller et mutualisez la logique dans un tableau si votre parc dépasse une dizaine de plugins prioritaires.

Pour une surveillance centralisée de l'ensemble du parc — contrôles hebdomadaires, alertes et rapports mensuels incluant les vulnérabilités — la plateforme de sécurité Sentinelo croise WPScan et l'analyse de réputation Sucuri pour chaque site WordPress sous maintenance, sans installation d'un plugin supplémentaire sur le site client.

Si vous gérez aussi des boutiques PrestaShop, la même vigilance s'applique aux modules tiers : consultez le guide sécuriser les modules PrestaShop pour adapter cette démarche à l'écosystème PrestaShop.

Pour un audit de durcissement plus complet allant au-delà des plugins — permissions fichiers, authentification à deux facteurs, en-têtes HTTP de sécurité — le guide sécurité WordPress pour agences couvre les étapes suivantes.