Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

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.

Décrire mon problème Discuter sur WhatsApp

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.

  • 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

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.

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

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’avez-vous constaté ?
Quelle plateforme ?
Depuis quand le problème est-il constaté ? (facultatif)

Plus l’infection est ancienne, plus elle a pu se propager dans les fichiers et la base de données.

Disposez-vous d’une sauvegarde saine ?

Une sauvegarde antérieure à l’infection change complètement la méthode de remise en état.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

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.

Pages liées