# Les modules et extensions abandonnés : le premier vecteur réel

> Avant le mot de passe faible, avant le serveur mal configuré, le point d’entrée le plus courant reste un module ou une extension que plus personne ne met à jour, installé pour une fonctionnalité ponctuelle puis oublié.

- Source canonique : [https://allaux.fr/securite/modules-et-extensions-abandonnes](https://allaux.fr/securite/modules-et-extensions-abandonnes)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Listez tous les modules installés, y compris ceux qui sont désactivés, et notez pour chacun la date de la dernière version publiée par son éditeur. Un module dont plus rien ne sort depuis des années et dont vous n’utilisez plus la fonction doit être supprimé du serveur, pas seulement désactivé : ses fichiers restent atteignables par le serveur web tant qu’ils sont présents dans le répertoire.

## Ce qu’est réellement un module abandonné

Un module abandonné n’est pas forcément un module ancien ou visiblement cassé. C’est un module installé un jour pour un besoin précis, un moyen de paiement, une bannière promotionnelle, une intégration réseau social, puis laissé en place sans être ni utilisé activement ni surveillé. Son éditeur peut avoir cessé son activité, arrêté de le maintenir, ou simplement ne plus publier de correctif pour une version ancienne encore installée sur votre boutique.

Le cœur du CMS, lui, continue d’évoluer. Chaque nouvelle version publie parfois des correctifs de sécurité qui concernent indirectement les modules, et de nouvelles failles sont régulièrement découvertes dans du code qui n’a pas changé depuis des années. Un module abandonné ne devient donc pas seulement inutile : il devient une zone du site qui s’écarte de plus en plus du niveau de sécurité du reste de l’installation.

| Valeur | Description |
|---|---|
| 39,1 % | des applications CMS compromises étaient déjà obsolètes au moment de l’infection |
| 13,97 % | des sites compromis avaient au moins une extension ou un thème vulnérable au moment de la remédiation |

Source : Rapport Sucuri 2023, Hacked Website & Malware Threat Report

## Le cas Slider Revolution : une extension qu’on ne sait même pas avoir

En décembre 2014, la campagne connue sous le nom de « SoakSoak » a compromis plus de 100 000 sites WordPress via une faille de l’extension Slider Revolution, selon le décompte publié à l’époque par Sucuri. La particularité de ce cas : l’extension était très souvent intégrée directement à l’intérieur de thèmes premium, sans que l’acheteur du thème ne sache même qu’elle s’y trouvait. Sans le savoir installée, elle n’était évidemment jamais mise à jour. Google a mis en liste noire plus de 11 000 domaines pendant cette campagne, d’après les analyses de Sucuri et de Graham Cluley. C’est l’exemple le plus clair d’un vecteur d’entrée qu’un marchand ne peut pas surveiller s’il ignore son existence.

## Même une extension bien maintenue peut être temporairement vulnérable

> CVE-2023-28121, une faille critique (score CVSS 9,8) du module WooCommerce Payments, installé sur plus de 600 000 sites, a déclenché des attaques massives à partir du 14 juillet 2023, avec un pic de 1,3 million de tentatives contre 157 000 sites le 16 juillet 2023. Le correctif est sorti en version 5.6.2, publié par un éditeur pourtant actif et sérieux. Le vrai risque n’est donc pas seulement l’abandon pur et simple : c’est l’écart de temps entre la sortie d’un correctif et son application effective sur votre boutique.

## Pourquoi certaines failles corrigées restent exploitables

Le module de liste de souhaits blockwishlist pour PrestaShop, en versions 2.0.0 à 2.1.0, contenait l’injection SQL référencée CVE-2022-31101, corrigée en 2.1.1. C’est le maillon qui rendait exploitable la faille du cœur CVE-2022-36408 (aussi référencée CVE-2022-31181), laquelle visait les versions 1.6.0.10 à 1.7.8.6 incluses et a été corrigée en 1.7.8.7. Mais sur toutes les boutiques où ce module précis n’a jamais été mis à jour ou remplacé, la porte d’entrée est restée ouverte bien après la publication du correctif : la faille n’avait pas disparu, elle avait simplement cessé d’être un problème pour ceux qui avaient agi.

## Comment repérer un module à risque sur votre boutique

1. **Vérifier la date de dernière mise à jour** — Dans le back-office, chaque module ou extension affiche généralement sa version et parfois sa date de publication. Un module qui n’a pas bougé depuis plusieurs années, alors que le cœur du CMS a changé plusieurs fois, mérite d’être vérifié.
2. **Vérifier qu’il reste disponible officiellement** — Un module qui a disparu du dépôt officiel ou de la marketplace de l’éditeur, alors qu’il reste actif sur votre site, ne recevra plus aucun correctif futur.
3. **Vérifier la compatibilité annoncée** — Un module qui annonce une compatibilité maximale très inférieure à la version actuelle de votre CMS a de fortes chances de ne plus être suivi activement par son éditeur.
4. **Lister les modules réellement utiles** — Un module installé pour un test ponctuel ou une campagne terminée depuis longtemps, mais toujours actif, augmente la surface d’exposition sans apporter aucun bénéfice.

## Pour aller plus loin

- **Injections SQL expliquées** — Le mécanisme technique derrière plusieurs des failles citées sur cette page. ([/securite/injections-sql-expliquees](/securite/injections-sql-expliquees))
- **Surveiller les failles qui concernent ma boutique** — Où et comment suivre les publications de failles avant qu’un attaquant ne les exploite. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Versions de PHP en fin de vie** — Un autre écart silencieux entre ce qui fonctionne encore et ce qui reste sécurisé. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))

## FAQ

### Comment savoir si un module que j’utilise a déjà été touché par une faille publiée ?

Je compare la liste des modules installés et leurs versions aux bases publiques de vulnérabilités connues, et je vérifie les journaux du site pour détecter une éventuelle exploitation déjà survenue.

### Dois-je supprimer tous les modules que je n’utilise plus ?

Oui dans la grande majorité des cas. Un module désactivé mais toujours présent sur le serveur reste souvent exécutable directement, ce qui ne le rend pas plus sûr qu’un module actif.

### Un module premium payant est-il à l’abri de ce risque ?

Non. CVE-2023-28121 concernait WooCommerce Payments, un module officiel maintenu activement. Le prix ou le sérieux de l’éditeur réduisent le risque mais ne l’éliminent jamais complètement.

### Comment savoir si une extension a été intégrée à l’intérieur de mon thème sans que je le sache ?

C’est un point souvent invisible depuis le back-office standard. Je vérifie directement dans les fichiers du thème la présence de bibliothèques tierces embarquées, comme ce fut le cas pour Slider Revolution dans de nombreux thèmes premium.

### À quelle fréquence faut-il vérifier ses modules ?

Une vérification à chaque mise à jour majeure du cœur du CMS, et un contrôle général au moins tous les trimestres, permet de repérer un module à l’arrêt avant qu’il ne devienne un problème.