# L’éditeur de mon module a disparu et la faille ne sera jamais corrigée

> Il existe des avis de sécurité qui se terminent par « aucun correctif ne sera publié ». Dans ce cas la mise à jour n’est pas une option, et désactiver le module ne suffit pas toujours : voici ce qui reste à faire.

- Source canonique : [https://allaux.fr/securite/editeur-du-module-a-disparu-faille-non-corrigee](https://allaux.fr/securite/editeur-du-module-a-disparu-faille-non-corrigee)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Bloquez l’accès HTTP au dossier du module au niveau du serveur web, en refusant le répertoire entier plutôt qu’en filtrant des extensions de fichiers. Vérifiez le blocage depuis l’extérieur, sans session d’administration ouverte et sans cache navigateur. Désactiver le module dans le back-office ne retire pas ses fichiers du serveur : les journaux et exports déjà écrits restent atteignables tant que la règle n’est pas en place.

## Quand l’avis se termine par « aucun correctif ne sera publié »

En mai 2026, un avis de sécurité a été publié pour un module de transport PrestaShop, upsshipping, édité par Agence Web 360. Référence CVE-2026-39079, score CVSS 8,6. Toutes les versions jusqu’à la 2.4.0 incluse sont concernées. Et l’avis précise qu’aucun correctif ne sera publié : l’éditeur n’est plus en activité.

La nature de l’exposition mérite d’être comprise avant d’agir. Le dossier de journaux du module était accessible publiquement. Les fichiers XML qu’il contient exposent les identifiants d’API UPS, le numéro de licence d’accès, les numéros de compte expéditeur, ainsi que des données personnelles de clients : noms, adresses postales, téléphones. Sur un cas réellement observé, ce dossier contenait plus de 2,3 millions de fichiers XML, environ 8,7 Go, couvrant février 2023 à avril 2026.

Ce n’est donc pas une faille qu’on exploite au sens habituel : c’est un stock de données qu’on lit. La distinction compte pour tout ce qui suit, parce qu’elle change le sens du mot « corriger ». Ici, corriger le code ne servirait à rien si les fichiers déjà écrits restent en place.

| Valeur | Description |
|---|---|
| 46 % | des vulnérabilités n’avaient pas de correctif au moment de leur divulgation publique |
| 35 % | des vulnérabilités divulguées en 2024 restaient sans correctif en avril 2025 |

Source : Patchstack, State of WordPress Security in 2026 (chiffres 2025) ; Wordfence, rapport annuel sur 2024

## Ce qui indique que vous êtes dans ce cas de figure

- L’avis de sécurité concernant le module indique explicitement qu’aucune version corrigée ne sera publiée.
- La page produit de l’éditeur, son site ou son espace client ne répondent plus, et aucun canal de support ne fonctionne.
- La dernière version publiée du module date de plusieurs années, alors que la boutique a changé de version majeure depuis.
- Le module écrit des journaux, des exports ou du cache à l’intérieur de son propre répertoire, sous la racine publique du site.
- Des identifiants de service tiers sont stockés en clair dans des fichiers déposés par le module.

## Pourquoi désactiver le module ne suffit pas

Désactiver un module dans le back-office coupe son exécution par la boutique. Ça ne retire pas ses fichiers du serveur. Un fichier resté en place sous la racine publique reste souvent atteignable directement par le serveur web, indépendamment de l’état du module dans l’administration : le serveur ne sait pas qu’une case a été décochée quelque part.

Et dans le cas qui nous occupe, le code n’est même pas le problème principal. Ce sont les fichiers déjà écrits. Ils contiennent des identifiants d’API et des données de clients, ils restent lisibles tant qu’ils sont là, que le module soit actif, désactivé ou en attente d’être remplacé. Un module désactivé depuis deux ans peut donc continuer à exposer deux ans d’historique.

Il faut séparer deux temps qu’on a tendance à confondre. Neutraliser l’exposition : c’est immédiat, ça ne dépend de personne d’autre que vous, et ça se fait sans toucher au fonctionnement de la boutique. Remplacer le module : c’est un projet, avec un choix de solution, des tests, une recette, parfois un changement de configuration côté transporteur. Le second ne doit jamais servir de raison pour retarder le premier.

## Ce que je fais, dans cet ordre

1. **Interdire l’accès HTTP au dossier concerné** — Au niveau du serveur web, dans la configuration du site ou les règles d’accès du répertoire, en refusant l’ensemble du dossier plutôt qu’en filtrant certaines extensions de fichiers. Je ne publie pas la configuration exacte ici : elle désigne le chemin exposé, et ce chemin n’a pas à circuler.
2. **Vérifier que le blocage fonctionne réellement** — Depuis l’extérieur, sans session d’administration ouverte et sans cache navigateur. Une règle écrite au mauvais endroit de la configuration ne produit aucune erreur : elle ne s’applique simplement pas.
3. **Purger les fichiers déjà écrits** — Après avoir gardé, hors de la racine publique, la copie dont vous aurez besoin pour qualifier ce qui a été exposé et sur quelle période.
4. **Réinitialiser les identifiants tiers** — Identifiants d’API UPS, numéro de licence d’accès, numéros de compte expéditeur. Chez le fournisseur, pas seulement dans la configuration de la boutique : un identifiant lisible depuis l’extérieur reste valide tant qu’il n’a pas été révoqué à la source.
5. **Vérifier l’absence d’activité frauduleuse** — Sur le compte transporteur : expéditions, étiquettes et facturations que vous ne reconnaissez pas, sur toute la période couverte par les fichiers.
6. **Supprimer le module, pas seulement le désactiver** — C’est la recommandation explicite de l’avis. Tant que les fichiers sont sur le serveur, le problème est suspendu, pas résolu.
7. **Évaluer les obligations liées aux données personnelles** — Des données de clients étaient lisibles : cette partie du dossier a ses propres règles et ses propres délais, indépendamment du travail technique.

## Des données clients lisibles, c’est une violation de données

> L’avis demande explicitement d’évaluer les obligations RGPD. Une violation de données est un incident de sécurité entraînant la destruction, la perte, l’altération ou la divulgation non autorisée de données personnelles, de manière accidentelle ou illicite : une exposition publique en fait partie, même sans preuve qu’une personne mal intentionnée soit passée. Toute violation doit être consignée dans un registre interne, y compris celles qui ne sont pas notifiées. Si elle présente un risque pour les droits et libertés des personnes, elle se notifie à la CNIL dans les 72 heures après en avoir pris connaissance. Si le risque est élevé, les personnes concernées doivent aussi être informées, avec des recommandations de protection. Ce sont les articles 33 et 34 du RGPD.

## Le seul critère qui compte pour choisir un remplaçant

Une fois l’exposition neutralisée, il reste le vrai sujet : par quoi remplacer un module dont vous avez besoin. Les fonctionnalités se comparent en une heure, et c’est ce que tout le monde fait. Ce qui décide de la suite, c’est autre chose : qui publie des correctifs, et à quelle fréquence.

Concrètement, avant d’acheter, je regarde la date de la dernière version publiée, le nombre de versions sorties sur les douze derniers mois, l’existence d’un canal où l’éditeur annonce ses correctifs de sécurité, et surtout sa réaction aux avis publiés le concernant : a-t-il publié une version corrigée, en combien de temps, et l’a-t-il dit publiquement. Un éditeur qui a déjà traité un avis correctement en traitera un autre correctement.

Le prix ne garantit rien à lui seul, et l’ancienneté non plus. Un module qui fait 80 % de ce que vous voulez mais dont l’éditeur publie des correctifs vaut mieux qu’un module parfait sur le papier et figé depuis trois ans. C’est le même raisonnement que pour le module que vous êtes en train de retirer : il fonctionnait très bien, jusqu’au jour où il a fallu quelqu’un pour le corriger.

## Pour aller plus loin

- **Modules et extensions abandonnés** — Pourquoi c’est le premier vecteur réel, et comment repérer ceux qui dorment sur votre boutique. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Surveiller les failles qui concernent ma boutique** — Où suivre les avis, y compris ceux qui se terminent sans correctif. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **Modules PrestaShop** — Installation, remplacement et compatibilité quand il faut changer de solution. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### Le module fonctionne très bien, dois-je vraiment le supprimer ?

Oui. Un module qui fonctionne mais que plus personne ne corrige n’est pas un module sûr, c’est un module dont la prochaine faille restera ouverte. Bloquer l’accès au dossier exposé vous donne du temps, ça ne vous donne pas le droit de rester.

### Bloquer le dossier au niveau du serveur, est-ce que ça suffit ?

C’est la mesure d’urgence, pas la solution. Elle ferme la lecture, mais elle ne supprime ni les fichiers déjà écrits, ni le code, ni le risque qu’une future migration ou un changement d’hébergement fasse sauter la règle sans que personne ne s’en aperçoive.

### Comment savoir si quelqu’un a réellement récupéré ces fichiers ?

Le plus souvent, on ne peut pas le prouver, surtout si les journaux d’accès du serveur ne remontent pas assez loin. L’absence de preuve d’accès n’est pas une preuve d’absence d’accès : l’analyse porte sur ce qui était exposé et pendant combien de temps.

### Puis-je faire corriger le module moi-même ?

Techniquement souvent oui, si le code n’est ni chiffré ni verrouillé par la licence. Mais vous devenez alors le mainteneur : la prochaine incompatibilité et la prochaine faille sont pour vous. Je le fais parfois comme mesure de transition, jamais comme solution définitive.

### Dois-je informer mes clients ?

Ça dépend du niveau de risque, et c’est justement l’objet de l’analyse. Ce qui est obligatoire dans tous les cas, c’est de consigner la violation dans votre registre interne, même quand vous concluez qu’elle ne nécessite ni notification ni information individuelle.

### Combien de temps faut-il pour remplacer un module de ce type ?

Le remplacement se compte en jours ou en semaines selon le paramétrage et les tests à refaire. La neutralisation de l’exposition, elle, se compte en heures, et c’est elle qui doit être faite en premier.