Plugins abandonnés : repérer ceux qui deviennent une porte d'entrée

Le tableau de bord WordPress signale les extensions obsolètes, mais ne détecte pas celles retirées du répertoire officiel

À la une

Dans cet article

En 2024, 97 % des failles WordPress recensées par Patchstack provenaient d’extensions tierces, et non du cœur du CMS
Un plugin est considéré à risque dès qu’il n’a reçu aucune mise à jour depuis plus de douze mois, seuil utilisé par le répertoire officiel WordPress.org
La vérification prend moins de cinq minutes par extension en croisant trois indicateurs précis dans le tableau de bord
Les failles de type RCE (exécution de code à distance) et injection SQL figurent parmi les plus fréquentes sur les plugins abandonnés
Cinq outils gratuits ou intégrés permettent d’automatiser la détection des extensions obsolètes sans installer de plugin supplémentaire
Un protocole de remplacement en quatre étapes limite le risque de casse fonctionnelle lors du retrait d’un plugin vulnérable

Sommaire

97 % des failles WordPress viennent des extensions : le chiffre qui résume le problème
Quatre signes concrets qu’un plugin est abandonné
Ce qui se passe réellement quand une faille plugin est exploitée
Vérifier chaque extension en moins de cinq minutes : la méthode
Outils pour détecter automatiquement les plugins obsolètes
Remplacer un plugin vulnérable sans casser le site : quatre étapes
Maintenir une pile d’extensions saine sur la durée
Plugin sans alternative : que faire quand aucun remplaçant n’existe

Sur un site WordPress standard comportant entre quinze et vingt-cinq extensions, au moins trois d’entre elles n’ont généralement reçu aucune mise à jour depuis plus d’un an, selon les données agrégées par Patchstack dans son rapport annuel 2024. Ces plugins dormants représentent la première surface d’attaque exploitée par les scripts automatisés qui ciblent le CMS. Identifier une faille plugin obsolète et la corriger avant qu’elle ne soit exploitée relève d’un contrôle de routine qui ne demande ni compétence avancée en développement, ni outil coûteux.

97 % des failles WordPress viennent des extensions : le chiffre qui résume le problème

Le rapport State of WordPress Security 2024 publié par Patchstack établit que 97 % des vulnérabilités enregistrées sur l’écosystème WordPress en 2023 provenaient de plugins. Les thèmes comptaient pour 3 %, le cœur du CMS pour moins de 1 %. Ce déséquilibre s’explique par un facteur structurel : n’importe quel développeur peut publier une extension sur le répertoire officiel, sans audit de code préalable obligatoire.

Parmi les extensions concernées, une part significative est tout simplement abandonnée par son auteur. Le plugin reste disponible au téléchargement, il continue de fonctionner sur les sites existants, mais plus personne ne corrige les failles découvertes après l’abandon. Le répertoire WordPress.org affiche un avertissement lorsqu’un plugin n’a pas été mis à jour depuis deux ans, mais le délai réel de danger commence bien avant : douze mois sans commit sur le dépôt SVN suffisent pour qu’une extension accumule des vulnérabilités non corrigées, selon les critères de la base de données CVE Details.

Le problème ne touche pas seulement les petites extensions de niche. En 2023, le plugin Jetstyle (plus de 200 000 installations actives) a été retiré du répertoire après la découverte d’une faille critique de type cross-site scripting restée sans correctif pendant sept mois. Les sites qui l’utilisaient encore sont restés exposés jusqu’au retrait, sans notification automatique dans le tableau de bord WordPress. Ce décalage entre la découverte d’une faille et sa correction effective constitue la fenêtre d’opportunité exploitée par les attaquants.

Quatre signes concrets qu’un plugin est abandonné

Comment savoir si un plugin installé sur un site est réellement abandonné ou simplement stable ? La distinction est importante : certaines extensions matures ne nécessitent que de rares mises à jour. Quatre indicateurs permettent de trancher :

1. Aucune mise à jour depuis plus de douze mois. Le répertoire WordPress.org affiche la date de dernière mise à jour sur la fiche de chaque extension. Au-delà d’un an sans modification, le risque d’incompatibilité avec les nouvelles versions de PHP et de WordPress augmente fortement. Depuis WordPress 6.3, le tableau de bord signale les extensions qui n’ont pas été testées avec la version majeure en cours.

2. Aucune réponse du développeur sur le forum de support. La page « Support » de chaque plugin sur WordPress.org montre les fils de discussion ouverts et leur statut. Un développeur actif répond aux signalements de bug dans un délai raisonnable. Quand les dernières questions restent sans réponse pendant plus de trois mois, l’extension est probablement orpheline.

3. Incompatibilité déclarée avec la version PHP courante. Un plugin qui ne déclare pas la compatibilité avec PHP 8.1 ou supérieur dans son fichier readme.txt pose un double problème : risque de warnings ou d’erreurs fatales à l’exécution, et probabilité élevée que le code contienne des fonctions dépréciées qui élargissent la surface d’attaque. Le passage à une version PHP récente expose immédiatement ces incompatibilités.

4. Retrait du répertoire officiel. WordPress.org peut retirer un plugin pour violation des règles ou faille de sécurité non corrigée. Le plugin disparaît alors du moteur de recherche interne, mais il reste installé et actif sur tous les sites qui l’utilisaient déjà. Aucune alerte automatique n’est envoyée à l’administrateur du site. Seule une vérification manuelle ou un outil de monitoring permet de détecter ce retrait.

Voir aussi Attaques par force brute sur la page de connexion : les bloquer efficacement

Ce qui se passe réellement quand une faille plugin est exploitée

La chaîne d’attaque typique sur un plugin obsolète suit un schéma reproductible, documenté par le projet OWASP. Comprendre ce déroulement aide à mesurer la gravité du risque.

Phase 1 : le scan automatisé. Des robots parcourent en continu les sites WordPress accessibles sur le web. Ils envoient des requêtes ciblées aux chemins d’URL connus des plugins vulnérables (par exemple /wp-content/plugins/nom-du-plugin/readme.txt) pour vérifier la présence et la version de l’extension. Ce processus est entièrement automatisé et ne cible pas un site en particulier : il ratisse large.

Phase 2 : l’exploitation. Dès qu’un plugin vulnérable est identifié, le script injecte du code malveillant en exploitant la faille connue. Les types d’exploitation les plus fréquents sur les plugins WordPress sont l’injection SQL (lecture ou modification de la base de données), le cross-site scripting stocké (insertion de scripts dans les pages servies aux visiteurs), et l’exécution de code à distance (RCE), qui donne un contrôle total sur le serveur. Un plugin de formulaire abandonné avec une faille d’upload non restreint peut suffire à déposer un webshell en quelques secondes.

Phase 3 : la persistance. L’attaquant installe une porte dérobée (backdoor) dans un fichier anodin du thème ou du répertoire wp-includes. Cette porte dérobée survit aux mises à jour classiques du cœur WordPress. Sans un protocole de nettoyage complet, le site reste compromis même après la suppression du plugin d’origine.

Phase 4 : la monétisation. Le site compromis est utilisé pour envoyer du spam, héberger du phishing, rediriger les visiteurs vers des pages malveillantes ou miner de la cryptomonnaie. Google détecte généralement ces comportements dans un délai de 24 à 72 heures et ajoute un avertissement « Ce site risque d’endommager votre ordinateur » dans les résultats de recherche, ce qui effondre le trafic organique.

Vérifier chaque extension en moins de cinq minutes : la méthode

L’audit d’un plugin installé ne nécessite pas de lire son code source. Cinq vérifications suffisent pour évaluer son niveau de risque et décider s’il doit être conservé, remplacé ou supprimé.

Étape 1 : vérifier la date de dernière mise à jour. Dans le tableau de bord WordPress, la page Extensions affiche la version installée. Comparer cette version avec celle publiée sur WordPress.org. Si l’écart dépasse un an, passer à l’étape suivante avec une vigilance accrue.

Étape 2 : consulter la base de vulnérabilités. Le site WPScan Vulnerability Database (wpscan.com) recense les failles connues par plugin et par version. Saisir le nom exact du plugin dans le moteur de recherche et vérifier si des CVE ouvertes concernent la version installée. Une faille classée critique (score CVSS supérieur à 7) sans correctif disponible justifie un retrait immédiat.

Étape 3 : vérifier la compatibilité PHP et WordPress. La fiche du plugin sur WordPress.org indique les versions testées. Un plugin non testé avec WordPress 6.x ou avec PHP 8.x présente un risque fonctionnel et sécuritaire accru.

Étape 4 : évaluer l’activité du développeur. Consulter le dépôt SVN ou GitHub lié au plugin. Compter les commits sur les douze derniers mois. Vérifier les réponses aux tickets de support sur WordPress.org. Un développeur qui ne répond plus depuis six mois a probablement abandonné le projet.

Étape 5 : tester la désactivation. Avant de supprimer un plugin suspect, le désactiver sur un environnement de staging ou après une sauvegarde complète. Parcourir les pages du site pour identifier d’éventuels dysfonctionnements. Si rien ne casse, le plugin peut être retiré. S’il casse quelque chose, chercher une alternative maintenue avant de procéder au remplacement.

Outils pour détecter automatiquement les plugins obsolètes

Plusieurs solutions permettent d’automatiser la veille sur l’état des extensions installées, sans multiplier les plugins de sécurité qui alourdissent eux-mêmes le site.

Outil	Type	Coût	Ce qu’il détecte	Limite principale
WP-CLI `plugin status`	Ligne de commande	Gratuit	Version installée, mises à jour disponibles, état activé/désactivé	Accès SSH requis
WPScan (CLI)	Scanner externe	Gratuit (25 requêtes API/jour)	Failles CVE connues par plugin et version	Quota limité en version gratuite
Patchstack	Service SaaS + plugin	Gratuit (base) / 89 €/an (pro)	Failles zero-day, alertes temps réel, virtual patching	Le virtual patching nécessite la version payante
Health Check (natif WP)	Page intégrée	Gratuit	Incompatibilités PHP, extensions inactives, version WordPress	Ne consulte pas les bases de vulnérabilités
ManageWP	Tableau de bord centralisé	Gratuit (base)	Mises à jour en attente sur plusieurs sites, notes de version	Ne signale pas les plugins retirés du répertoire

La commande wp plugin list --format=table exécutée via WP-CLI reste la méthode la plus rapide pour obtenir un inventaire complet. Combinée à un script cron hebdomadaire, elle permet de recevoir par courriel la liste des plugins dont la version installée diffère de la version disponible. Pour les sites gérés sans accès SSH, la page Santé du site (Tableau de bord > Outils > Santé du site) fournit un diagnostic similaire, quoique moins détaillé.

L’outil WPScan, disponible en ligne de commande, interroge sa propre base de vulnérabilités et produit un rapport classé par niveau de criticité CVSS. L’intégrer dans un pipeline de déploiement versionné avec Git garantit qu’aucune mise en production n’embarque un plugin présentant une faille connue.

Remplacer un plugin vulnérable sans casser le site : quatre étapes

Le retrait d’un plugin obsolète ne se résume pas à cliquer sur « Supprimer ». Certaines extensions inscrivent des données en base, ajoutent des tables personnalisées, modifient le fichier .htaccess ou injectent des shortcodes dans les contenus. Un retrait brutal peut provoquer des erreurs 500, des shortcodes affichés en clair sur les pages, ou des tables orphelines qui encombrent la base de données.

Étape 1 : sauvegarder. Réaliser une sauvegarde complète (fichiers + base de données) et vérifier qu’elle est restaurable. Une sauvegarde non testée n’est pas une sauvegarde.

Étape 2 : identifier les dépendances. Rechercher dans le contenu du site les shortcodes, les widgets et les blocs Gutenberg liés au plugin. La commande wp post list --post_content='[shortcode_du_plugin' --format=table via WP-CLI liste tous les articles et pages qui utilisent un shortcode donné. Si le plugin ajoute un type de contenu personnalisé (custom post type), recenser les publications concernées.

Étape 3 : installer l’alternative avant de désactiver. Configurer le plugin de remplacement et migrer les données nécessaires pendant que l’ancien plugin est encore actif. Certains plugins de formulaire, par exemple, permettent d’exporter les soumissions au format CSV avant la migration. Vérifier que les URL des pages de formulaire restent identiques pour éviter les erreurs 404 sur les pages indexées.

Étape 4 : désactiver, vérifier, supprimer. Désactiver l’ancien plugin, parcourir les pages critiques du site pour détecter les anomalies, puis supprimer définitivement l’extension et ses fichiers résiduels dans /wp-content/plugins/. Après suppression, lancer un nettoyage des tables orphelines laissées par le plugin dans la base de données.

Maintenir une pile d’extensions saine sur la durée

La meilleure protection contre les failles de plugins obsolètes reste une politique stricte de gestion des extensions, appliquée dès l’installation du site et maintenue à chaque intervention.

Limiter le nombre d’extensions installées. Un site vitrine fonctionne correctement avec dix à quinze plugins. Au-delà de vingt, chaque extension supplémentaire augmente la surface d’attaque, le temps de chargement et la complexité de maintenance. Avant d’installer un nouveau plugin, vérifier si la fonctionnalité peut être obtenue par un appel API, un extrait de code dans le fichier functions.php du thème enfant, ou une fonctionnalité native de WordPress.

Activer les mises à jour automatiques pour les extensions de confiance. Depuis WordPress 5.5, il est possible d’activer les mises à jour automatiques extension par extension. Pour les plugins dont l’éditeur suit un cycle de publication régulier et dont le changelog ne contient pas de modifications destructives (breaking changes), cette option réduit considérablement la fenêtre d’exposition aux failles connues.

Planifier un audit trimestriel. Bloquer une heure par trimestre pour passer en revue la totalité des extensions installées. Supprimer celles qui sont désactivées (un plugin désactivé mais présent sur le serveur reste exploitable si ses fichiers PHP sont accessibles via une URL directe). Vérifier les dates de mise à jour et les avis de sécurité publiés depuis le dernier audit.

Coupler la veille à une protection périmétrique. Un pare-feu applicatif (WAF) comme celui intégré à Cloudflare ou à Sucuri bloque les tentatives d’exploitation connues même lorsque le plugin vulnérable est encore installé. Cette couche de protection ne remplace pas la mise à jour, mais elle achète du temps entre la publication d’une faille et l’application du correctif. La double authentification sur l’interface d’administration complète cette défense en profondeur en empêchant l’exploitation des failles qui nécessitent un accès authentifié.

Enfin, garder une trace écrite de chaque extension installée, de sa fonction et de la date de son dernier audit facilite la reprise par un autre intervenant. Un simple tableur partagé ou un fichier texte versionné avec le reste du site suffit. Cette documentation évite les situations où personne ne sait pourquoi un plugin est installé ni s’il est encore utilisé, ce qui conduit systématiquement à le garder « par précaution », c’est-à-dire à accumuler du risque passif.

Plugin sans alternative : que faire quand aucun remplaçant n’existe

Certains plugins abandonnés remplissent une fonction très spécifique pour laquelle il n’existe pas d’alternative directe sur le répertoire WordPress.org. Trois options permettent de gérer cette situation sans laisser une faille ouverte.

Option 1 : forker le plugin. Le code des extensions WordPress est distribué sous licence GPL. Il est donc légalement possible de créer une copie du plugin, d’appliquer les correctifs de sécurité nécessaires, et de maintenir cette version en interne. Cette approche convient aux équipes disposant d’un développeur capable de lire du code PHP et de suivre les bulletins de sécurité. Le fork doit être versionné dans un dépôt Git distinct pour tracer les modifications appliquées.

Option 2 : isoler le plugin. Si le plugin n’est utilisé que pour une fonctionnalité secondaire (un widget de sidebar, un shortcode sur une page peu visitée), restreindre son chargement aux seules pages qui l’utilisent. Des plugins comme Asset CleanUp permettent de désactiver le chargement des scripts et des styles d’une extension sur les pages où elle n’est pas nécessaire, réduisant ainsi la surface d’attaque aux seules URL concernées.

Option 3 : reconstruire la fonctionnalité sans plugin. Un formulaire de contact basique, un carrousel d’images, un bouton de partage sur les réseaux sociaux : beaucoup de fonctionnalités couramment déléguées à des plugins peuvent être codées en quelques dizaines de lignes dans le thème enfant ou implémentées avec les blocs natifs de l’éditeur WordPress. Supprimer la dépendance au plugin élimine définitivement le risque de faille lié à cette fonctionnalité.

Quelle que soit l’option choisie, la fonctionnalité rendue par le plugin doit être évaluée au regard du risque qu’elle fait peser sur le site. Un widget de statistiques visiteurs dont le plugin est abandonné depuis deux ans ne justifie pas d’exposer l’intégralité du site à une injection SQL. La règle de décision est simple : si le coût du remplacement dépasse la valeur de la fonctionnalité, supprimer la fonctionnalité.

À retenir

Vérifiez la date de dernière mise à jour de chaque plugin installé : au-delà de douze mois, le risque de faille non corrigée est élevé
Croisez la version installée avec la base WPScan pour détecter les CVE ouvertes avant qu’elles ne soient exploitées
Supprimez systématiquement les plugins désactivés : leurs fichiers PHP restent accessibles et exploitables sur le serveur
Sauvegardez et testez la restauration avant de retirer un plugin vulnérable, pas après
Planifiez un audit trimestriel de toutes les extensions pour maintenir une pile propre dans la durée

Questions fréquentes

Comment vérifier si un plugin WordPress contient une faille connue ?

Consulter la base de données WPScan (wpscan.com) en saisissant le nom exact du plugin. Le site affiche les CVE associées à chaque version, classées par score de criticité CVSS. La commande wpscan --url monsite.fr --enumerate vp automatise cette vérification pour toutes les extensions installées en une seule opération.

Un plugin désactivé représente-t-il un risque de sécurité ?

Oui. Un plugin désactivé reste physiquement présent dans le répertoire /wp-content/plugins/. Ses fichiers PHP sont accessibles par URL directe et peuvent être exploités si une faille permet l’exécution de code sans passer par le mécanisme d’activation de WordPress. La recommandation est de supprimer tout plugin désactivé qui n’est pas destiné à être réactivé dans un délai proche.

WordPress prévient-il quand un plugin est retiré du répertoire officiel ?

Non. Lorsqu’un plugin est retiré de WordPress.org pour raison de sécurité, aucune notification n’est envoyée aux administrateurs des sites qui l’utilisent. Le plugin continue de fonctionner normalement. Seule une vérification manuelle sur le répertoire ou l’utilisation d’un outil comme Patchstack permet de détecter ce retrait.

Combien de plugins peut-on installer sans compromettre la sécurité d’un site ?

Il n’existe pas de limite technique, mais les bonnes pratiques recommandent de rester en dessous de quinze à vingt extensions sur un site vitrine. Chaque plugin ajouté augmente la surface d’attaque, le nombre de dépendances à surveiller et le temps de chargement. L’enjeu n’est pas le nombre absolu, mais la capacité à maintenir chaque extension à jour et à vérifier régulièrement son état de sécurité.

Que faire si un plugin indispensable n’est plus maintenu par son développeur ?

Trois solutions existent : forker le plugin sous licence GPL et appliquer soi-même les correctifs de sécurité, isoler son chargement aux seules pages qui l’utilisent pour réduire la surface d’attaque, ou reconstruire la fonctionnalité directement dans le thème enfant sans dépendance externe. Si aucune de ces options n’est viable, la suppression de la fonctionnalité est préférable au maintien d’une faille ouverte.

À quelle fréquence faut-il auditer ses extensions WordPress ?

Un audit trimestriel constitue un bon compromis entre vigilance et charge de travail. Cet audit consiste à vérifier les dates de mise à jour, consulter les bases de vulnérabilités, supprimer les extensions désactivées et confirmer la compatibilité avec la version PHP et WordPress en cours. Pour les sites à fort trafic ou traitant des données sensibles, un audit mensuel est recommandé.

Damien Roux

Damien Roux est spécialiste de l'hébergement web. Fondateur de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress.