Module de transport PrestaShop inconnu : souvent une porte
Comme un module de paiement fantôme, un transporteur inconnu est souvent une porte : PHP au checkout, appels sortants, parfois un skimmer collé « pour la map ». Désactivez, inspectez le dossier, ne le « mettez pas à jour » depuis une archive douteuse.
Comme un module de paiement fantôme. Désactivez, inspectez le dossier, cherchez des appels sortants. Ne le « mettez pas à jour » depuis une archive douteuse.
Pourquoi le transport, pas seulement le paiement
Le tunnel PrestaShop charge les modules carrier à l'étape livraison — parfois aussi en header (widget de points relais, map, estimation). Un PHP exécuté là a le droit d'injecter du JS sur des pages proches du paiement. Les attaquants le savent : moins surveillé qu'un module « Stripe ». Un employé fantôme installe « Colissimo Pro v99 » la même nuit. Employé, skimmer. Un module « estimation de frais » chargé sur toutes les fiches produit élargit encore la surface : le JS n'attend pas le tunnel. Testez une fiche, le panier, puis le checkout, pas seulement l'étape transporteur.
Un vrai besoin métier (nouveau transporteur) se fait depuis Addons / l'éditeur officiel, pas depuis un zip « envoyé par un prospect ».
Reconnaître un module qui n'a rien à faire là
Nom proche d'un officiel (`colissimo` vs `colissimo_pro_v2` vs `colissim0`). Auteur vide, date de fichiers groupée à 3 h, pas de licence, dossier avec un seul `index.php` opaque. Un transporteur dans la liste des carriers que personne n'utilise en prod. Comparez à la liste « ce qu'on a vraiment sous contrat ».
Désactiver n'est pas supprimer le PHP
Un module désactivé reste sur le disque ; un include / un override peut encore tourner. Après archive (zip hors web pour preuve), retirez le dossier une fois lu. Les tables `ps_carrier` / `ps_module` : notez l'id. Ne TRUNCATE pas. Cadre : PrestaShop ordre.
Ce qu'on lit dans le dossier modules/
Grep `curl`, `file_get_contents`, `eval`, `base64_decode`, des hôtes inconnus, des champs `card`, `cc_number`. Un `logo.png.php`. Des fichiers hors de l'arbre habituel (`vendor` minifié d'une ligne). Comparez au zip officiel si l'éditeur existe. Un module « sans éditeur » : partez du principe qu'il est hostile.
- Archive du dossier avant retrait.
- Grep sortants et eval.
- Checksum vs zip officiel si possible.
Overrides et hooks sur le tunnel
`override/classes/Carrier.php`, hooks `displayHeader`, `displayAfterCarrier`, `actionCarrierUpdate`. Un override survit à la désactivation du module. Comparez `override/` à un cœur propre. Le thème `modules/nomcarrier/` aussi.
Appels sortants, licences, et « tracking »
Un vrai module Colissimo parle aux API Colissimo. Un faux parle à un VPS en `.xyz` « pour la licence ». Les journaux firewall / `allow_url_fopen` aident. Coupez le module avant de « tester la licence ». Les webhooks « tracking » vers une URL inconnue : même famille que webhooks paiement.
Transporteurs natifs vs zip marketplace
Les carriers créés dans l'admin (poids / prix) sans module PHP sont moins dangereux (pas de code). Le danger, c'est le module. Un zip « ThemeForest pack » qui ajoute cinq transporteurs : lisez-les un par un. Stripe officiel vs nulled — même discipline de source.
Après : recoller un transporteur officiel
Install depuis Addons / compte transporteur, pas depuis l'archive de l'incident. Retestez checkout + livraison + HTML. Caches Presta. Employés et clés relus. Guide, service, créer un compte.
- Module inconnu archivé puis hors disque.
- Overrides / hooks nettoyés.
- Tunnel HTML relu.
- Officiel recolle depuis la source éditeur.
Livraison, checkout et le JS qui se charge trop tôt
Beaucoup de modules points relais injectent leur JS dès le panier, pas seulement à l'étape transporteur. Un skimmer collé dans ce JS voit donc plus de pages que « la livraison ». Testez panier, adresse, livraison, paiement : quatre sources HTML. Un widget de carte (OpenStreetMap / Google) chargé depuis un hôte inconnu n'est pas « la map Colissimo ».
Les webhooks « colis scanné » vers une URL que vous n'avez pas sont un canal d'exfiltration des adresses de livraison — données personnelles, parfois plus sensibles qu'un email. Révoquez-les comme des webhooks de paiement. Si le module a pu lire `customers`, le constat fuite s'applique, même sans carte bancaire.
Après retrait, les commandes en cours avec ce carrier : passez-les sur un transporteur officiel ou traitez-les à la main. Ne réactivez pas le zip de l'incident « le temps d'expédier le vendredi ». C'est exactement comme rouvrir un module Stripe nulled pour encaisser le week-end.