Repérer et remplacer les extensions abandonnées

Ce qu'est vraiment une extension abandonnée

Une extension abandonnée n'est pas « un peu vieille ». C'est un composant dont personne ne publie plus de correctif. Deux ans sans version, dépôt Git mort, page WordPress.org figée, e-mail de l'auteur en bounce : le marché des failles publiques, lui, ne s'arrête pas. Les bots testent les versions connues en continu.

Incompatible avec le cœur actuel, « non testé avec les 3 dernières versions », fork sans mainteneur : ce sont des signaux, pas une preuve d'infection. Beaucoup de sites tournent encore avec un plugin de galerie de 2019. Tant que personne n'a cherché cette version, le site tient. Le jour où un CVE sort, le délai se compte en heures, pas en trimestres.

Le soir d'un piratage, on confond souvent « l'entrée d'hier » et « la porte de demain ». L'entrée peut être un mot de passe FTP. La porte de demain est cette extension que personne ne veut toucher parce que le slider de la home en dépend. Les deux sujets se traitent, dans cet ordre : fermer hier, lister demain. Mettre à jour sans casser fixe le moment des maj.

Signaux à lire sans se presser

À froid, ouvrez la liste des extensions. Pour chacune : date de dernière mise à jour, nombre d'installations actives s'il est public, présence d'un changelog récent, existence d'un support. Un plugin à 800 000 installations mis à jour il y a trois semaines n'est pas le même risque qu'un add-on à 200 installations silencieux depuis 2021.

Auteur introuvable, site vitrine de l'éditeur hors ligne, société liquidée : notez-le. « Premium » n'est pas un critère de santé. Des extensions payantes meurent aussi. Inversement, un plugin gratuit bien tenu vaut mieux qu'un pack Telegram. Voir thèmes et plugins hors circuit.

Ne jugez pas au nom. Un « security booster » abandonné est pire qu'une simple galerie morte : il a souvent des droits larges et un cron. Un formulaire de contact figé depuis 2018 est, historiquement, une porte fréquente. L'inventaire se fait en tableau, pas en impression.

• Dernière version : plus de 24 mois.
• Avis d'incompatibilité avec le cœur actuel.
• Auteur ou société introuvable.
• Fichiers encore présents alors que l'extension est « désactivée ».

Pourquoi « désactiver » ne ferme rien

Désactiver retire le hook. Ça n'efface pas `wp-content/plugins/nom-du-plugin/`. Les bots demandent des chemins connus (`/wp-content/plugins/ancien-formulaire/upload.php`). Un fichier resté là, même « off », suffit. Il faut retirer le dossier, une fois la fonction remplacée ou acceptée comme perdue.

Sur Joomla, désinstaller depuis l'admin est plus propre que décocher. Sur Drupal, `composer remove` puis déploiement, pas seulement « uninstall » en UI si le code reste dans `contrib`. Sur PrestaShop, un module désactivé reste dans `/modules`. Le réflexe est le même : le disque, pas seulement l'écran.

Ne supprimez pas au hasard le soir de l'incident. Un plugin infecté est parfois aussi le seul à tenir une page métier. Notez, isolez (renommer le dossier le temps de l'analyse), remplacez à froid. Ne pas supprimer les fichiers au jugé évite de casser l'affichage sans fermer l'entrée.

Inventaire après un piratage

Après un incident, la liste sert au constat. Quelle extension était la plus probable comme entrée ? Laquelle est seulement une dette ? Vous n'aurez pas toujours la réponse : un access.log avec un POST vers un PHP d'extension aide plus qu'un scan. Demandez les journaux à l'hébergeur. Voir lire les journaux d'accès.

Un plugin de sécurité installé pendant l'attaque n'est pas « abandonné ». Il est surtout trop tôt. On le pose à la fin. Un cleaner qui a « réparé » des fichiers d'une extension officielle brouille la comparaison au zip. Gardez l'archive d'origine.

Si l'hébergeur a cité un chemin (`/wp-content/plugins/xyz/foo.php`) dans un mail o2switch ou un ticket OVH, partez de ce chemin, mais ne vous y limitez pas : la porte est souvent ailleurs. Le guide suspension et la page compte suspendu décrivent le constat à joindre.

Remplacer la fonction, pas seulement le nom

Remplacer, c'est retrouver ce que l'extension faisait (slider, FAQ, réservation, export comptable) et choisir un composant encore tenu, ou du code métier court. Recoller un autre plugin abandonné « parce que l'interface se ressemble » recommence le cycle dans dix-huit mois.

Budget : un plugin payant maintenu coûte moins cher qu'un second piratage. Le coût réel d'un incident aide à arbitrer. Si personne dans l'équipe ne sait recréer le slider, déléguez le remplacement, pas seulement le nettoyage.

Données : certains plugins stockent leurs réglages en options ou en tables dédiées. Migrer la fonction sans perdre le contenu demande un export. Faites-le après copie du site, pas en live sur un compte encore ouvert. Sauvegarder un site déjà piraté rappelle où stocker cette copie.

Constructeurs, add-ons et packs fourre-tout

Elementor, Divi, WPBakery : le cœur est souvent tenu. Les add-ons « 40 widgets » d'un tiers le sont moins. Dans nos constats, l'entrée passe plus souvent par l'add-on que par le constructeur. Listez-les nommément. Voir aussi add-ons Elementor abandonnés.

Les packs « 50 plugins en une install » et les suites « tout-en-un » mortes sont des surfaces énormes. Vous n'utilisez peut-être que le module FAQ ; le module upload, lui, est encore là. Désinstaller le pack entier, puis réinstaller uniquement ce qui est maintenu, est plus sûr que de garder le monolithe.

Un constructeur nulled n'aura jamais de maj propre. Changer de constructeur après un hack est un projet, pas une soirée. Nettoyez d'abord, tenez, planifiez la refonte. Melanger refonte et incident double le risque de perte de contenu. Site piraté et refonte en même temps détaille ce piège.

Joomla, Drupal, PrestaShop : les mêmes critères

Joomla : extensions dans l'admin, parfois un composant dans `/components` plus touché que le cœur. Super User fantôme et PHP dans `/images` restent les classiques. Le guide Joomla piraté et l'article extensions et Super User déplient l'ordre.

Drupal : modules contrib non maintenus, fichiers hors profil dans `/sites/default/files`. Une maj tardive du cœur ne retire pas ce qui a été déposé. Voir Drupal piraté et modules contrib.

PrestaShop et Magento : un module de paiement ou de transport abandonné est plus grave qu'un module de galerie. Le checkout change l'urgence. Sur un CMS oublié (SPIP, TYPO3), l'extension morte et le PHP ancien se cumulent. TYPO3, SPIP ou CMS oublié décrit ce cas.

Tenir la liste pour ne plus oublier

Un tableur suffit : nom, rôle métier, date de dernière version, décision (garder / remplacer / retirer), échéance. Relisez-le à chaque trimestre, pas seulement après un ticket d'abus. C'est le seul antidote au « on verra plus tard » qui produit le prochain incident.

Moins de composants, moins de portes. Chaque plugin installé « pour tester » et jamais retiré est une ligne de plus. Le principe du moindre privilège s'applique aussi aux extensions : pas de droits d'admin pour un slider.

Si la liste dépasse ce que vous savez arbitrer, déclarez le site. Un constat écrit peut inclure les remplacements prioritaires, sans prétendre tout migrer le jour du nettoyage. La garantie trente jours couvre la même faille, pas le chantier de refonte.

• Tableau à jour, pas une capture d'écran de 2023.
• Dossiers réellement absents du disque après retrait.
• Remplacements planifiés, pas improvisés un dimanche.