vendredi 25 septembre 2026

À propos

Contact

Sécurité

Extensions abandonnées toujours actives : le risque silencieux d’un site

Un audit révèle des extensions non mises à jour depuis trois ans encore actives sur des sites clients. Méthode pour les recenser automatiquement avec WP-CLI et évaluer le risque réel.

Par Clément Hadrot • 17 novembre 2022 • 6 min de lecture • Aucun commentaire
Extensions abandonnées toujours actives : le risque silencieux d'un site

En reprenant la maintenance d’un portefeuille de douze sites pour une agence, notre première étape n’est jamais de regarder le code personnalisé : c’est de dresser l’inventaire complet des extensions actives sur chaque site, avec leur date de dernière mise à jour et leur statut auprès de leur dépôt d’origine. Sur ce lot, quatre sites différents utilisent une même extension de galerie photo dont la dernière version date de plus de trois ans, alors que WordPress lui-même est passé par plusieurs versions majeures depuis. Aucune mise à jour n’a jamais été proposée pour elle depuis son installation initiale.

Ce n’est pas nécessairement le signe d’une vulnérabilité déjà découverte — mais c’est un signal de risque à part entière, souvent invisible parce que WordPress n’affiche par défaut qu’une alerte pour les extensions dont une mise à jour est disponible, jamais pour celles qui ont simplement cessé d’en recevoir.

Pourquoi une extension abandonnée est un risque, même sans faille connue

Le raisonnement se déroule en plusieurs temps. D’abord, une extension activement maintenue bénéficie de corrections de sécurité au fil de l’évolution de PHP, de WordPress et des techniques d’attaque : une fonction jugée sûre il y a cinq ans peut se révéler vulnérable à la lumière de nouvelles méthodes d’exploitation découvertes depuis, et seule une équipe encore active peut réagir à cette évolution. Ensuite, une extension abandonnée reste un point d’entrée statique, dont le code ne change plus, ce qui laisse à d’éventuels chercheurs en sécurité (ou attaquants) tout le temps nécessaire pour l’analyser en profondeur, sans crainte qu’un correctif rende leurs travaux obsolètes. Enfin, et c’est le risque le plus spécifique à l’écosystème WordPress, une extension abandonnée par son auteur original devient parfois la cible d’un rachat par un tiers malveillant, qui en profite pour y injecter du code indésirable dans une future mise à jour — un scénario traité plus en détail dans un autre article, mais qui commence toujours par la même situation initiale : une extension que plus personne ne surveille activement.

Recenser systématiquement avec WP-CLI

L'essentiel à retenir : Une extension active et jamais mise à jour n'est pas neutre ; Aucune alerte native ne signale un abandon éditeur ; wp plugin list rend le recensement systématique

Faire ce constat extension par extension, à la main, sur un portefeuille de plusieurs sites n’est pas réaliste dans la durée. WP-CLI permet d’automatiser ce recensement en quelques commandes, exécutables via un script parcourant l’ensemble des sites gérés :

wp plugin list --format=json --fields=name,status,version,update

Cette commande liste chaque extension active, sa version installée, et si une mise à jour est disponible selon WordPress.org ou la source configurée. Elle ne donne toutefois pas directement la date de dernière publication de l’extension, information qu’il faut croiser avec le dépôt officiel pour les extensions qui en proviennent :

#!/usr/bin/env bash
# Recense les extensions actives et leur date de dernière mise à jour connue
wp plugin list --status=active --field=name | while read -r slug; do
    date_maj=$(curl -s "https://api.wordpress.org/plugins/info/1.0/${slug}.json" \
        | python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('last_updated','inconnu'))")
    echo "${slug};${date_maj}"
done

Le résultat, trié par date, fait apparaître immédiatement les extensions les plus anciennes sans mise à jour récente. Une extension avec un champ last_updated vieux de plus de deux ans mérite systématiquement une vérification manuelle : est-elle toujours listée comme « fermée » sur le répertoire officiel (un statut que WordPress.org attribue explicitement aux extensions retirées, souvent pour des raisons de sécurité non corrigées), ou simplement stable et sans besoin d’évolution ?

Vérifier le statut réel auprès du répertoire officiel

Le répertoire WordPress.org retire parfois une extension de la distribution publique sans la supprimer du site où elle est déjà installée : le site continue de fonctionner normalement, mais l’extension n’apparaît plus dans les résultats de recherche ni dans les mises à jour proposées, un signal fort souvent manqué faute de vérification active. La page dédiée à l’extension sur le répertoire officiel affiche alors une mention explicite de fermeture, parfois accompagnée d’une raison sommaire :

curl -s "https://api.wordpress.org/plugins/info/1.0/nom-extension.json" | grep -i "closed\|error"

Croiser systématiquement chaque extension ancienne avec cette vérification a permis, sur ce portefeuille de douze sites, de découvrir que l’une des quatre extensions repérées était effectivement fermée sur le répertoire officiel depuis plusieurs mois, sans qu’aucun client n’en ait été informé, faute d’alerte native dans l’administration WordPress pour ce cas précis.

Décider quoi faire d’une extension abandonnée

Le recensement n’est que la première étape ; la décision qui suit dépend du rôle réel de l’extension sur le site :

  • Si une alternative activement maintenue couvre la même fonctionnalité, la migration reste la solution la plus sûre à moyen terme, même si elle demande un effort de test.
  • Si l’extension est trop spécifique ou trop intégrée pour être remplacée rapidement, un audit de code ciblé (recherche de fonctions à risque comme unserialize, eval, requêtes SQL sans $wpdb->prepare) permet au moins d’évaluer son niveau de risque réel, plutôt que de se fier uniquement à son ancienneté.
  • Dans tous les cas, une extension jugée trop risquée pour être remplacée immédiatement doit être compensée par une surveillance renforcée à son niveau : restriction d’accès à ses points d’entrée spécifiques, journalisation accrue de son activité.

Sur ce portefeuille de douze sites, ce recensement trimestriel est devenu une clause à part entière du contrat de maintenance : chaque client reçoit désormais un rapport listant les extensions vieillissantes avant qu’un incident ne les révèle.

Ce que cet audit ne couvre pas

Ce recensement ne traite pas du scénario, distinct, d’une extension rachetée intentionnellement par un acteur malveillant qui continue pourtant de publier des mises à jour apparemment légitimes — un risque qui ne se détecte pas par simple vérification de la date de dernière publication, puisque celle-ci reste récente, et qui fait l’objet d’un traitement séparé.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi