Un module de paiement que personne n'a installé

Ce n'est pas un plugin « oublié »

Les boutiques accumulent des modules. Un vieux PayPal, un Stripe de test, un « paiement 3x » jamais branché. Avant de crier au pirate, demandez à l'agence et au comptable. Le signal pirate, c'est un module apparu cette semaine, avec un nom proche de l'officiel (`stripe-gateway-pro`, `paypal-secure-checkout`) et aucun contrat derrière.

Les packages nuls et les copies « officielles » téléchargées sur un forum portent déjà le skimmer. S'il est « là depuis la migration de 2022 », ce n'est pas moins grave : c'est plus long. La date d'installation (fichier, table modules) tranche.

Un module que vous avez installé et qui a été modifié, c'est encore un autre cas : le fichier officiel est devenu autre chose. Comparez le zip du prestataire à ce qui est sur le disque. Une seule classe PHP de 200 Ko dans un module qui en fait 20, ce n'est pas une mise à jour mineure.

Désactiver sans effacer les fichiers

Désactiver coupe le hook sur le checkout. Supprimer efface les commentaires, les dates, parfois un `readme` avec une URL d'origine. Copiez d'abord le dossier hors serveur, puis désactivez dans l'admin. Le zip de preuve ne vit pas dans `modules/` : il part sur votre poste.

Si vous ne pouvez plus entrer dans l'admin, renommez le dossier via SFTP (`stripe-fake` → `stripe-fake.off`). C'est une désactivation de fait. Ne le laissez pas téléchargeable à l'URL `/modules/stripe-fake/`.

Notez l'heure. Elle aligne les journaux PSP (« premières transactions bizarres ») et les journaux web (premier `POST` vers le module). Sans heure, tout le monde raconte une semaine différente.

• Copie zip hors serveur.
• Désactivation admin ou renommage du dossier.
• Heure notée, captures du checkout.
• Pas de suppression tant que le constat n'est pas écrit.

Lire le module comme une preuve

Ouvrez les fichiers PHP : domaines en dur, `eval`, `base64_decode`, un endpoint qui poste le numéro de carte vers une IP. Même sans être développeur, un `file_get_contents('http://…')` au milieu d'un checkout n'est pas du Stripe officiel.

Les dates de fichiers : un `payment.php` modifié cette nuit alors que le `logo.png` date de 2021. Cette date est l'heure d'entrée la plus parlante du dossier, souvent plus que `access.log`.

Cherchez un second fichier à la racine du site avec le même horodatage. Le module est l'outil ; le webshell est la main. Les deux se posent dans la même session FTP.

Le tunnel vu par un client, pas par l'admin

Connecté en admin, vous voyez parfois le vrai Stripe. Le visiteur mobile, lui, a un iframe. Testez le checkout en navigation privée, sur téléphone, avec un article à 1 € si besoin (annulez). Regardez le nom de domaine du formulaire de carte : `checkout.stripe.com` n'est pas `stripe-secure.example.ru`.

Enregistrez HAR ou une capture avec la barre d'adresse. C'est ce que le PSP et l'assureur comprennent. « Je crois que c'était bizarre » ne l'est pas.

Si la page de paiement est une fausse page bancaire sur votre domaine, coupez cette URL tout de suite. Le reste de l'ordre (copie, mots de passe) reprend ensuite.

Prévenir le PSP sans roman

Stripe, PayPal, votre banque, votre agrégateur : un e-mail factuel. Date de découverte, que le module n'est pas le vôtre, qu'il est désactivé, que vous ne savez pas encore si des PAN ont transité. Pas de « on a été hacké tout est perdu ». Ils ont des procédures ; ils ont besoin d'une date et d'une URL.

Si vous avez un contrat « paiement sécurisé » affiché en pied de page, ne le laissez pas en ligne au-dessus d'un tunnel douteux. Un bandeau factuel ou une fermeture temporaire du checkout vaut mieux qu'une mention mensongère. Voir aussi informer sa banque.

Ne rouvrez pas le vrai module « pour ne pas perdre le week-end » tant que le faux est seulement désactivé et que l'entrée n'est pas trouvée. Deux modules qui s'accrochent au même hook, le visiteur peut encore tomber sur le mauvais.

Woo, Presta, Magento : où il se loge

WooCommerce : `wp-content/plugins/`, parfois un mu-plugin qui réécrit le checkout, parfois un snippet dans `wp_options` (`woocommerce_gateway_*`). Un plugin « officiel » dont le fichier principal a gonflé se compare au zip wordpress.org, pas à l'écran « Extensions ».

PrestaShop : `modules/`, et la table `ps_module`. Un module non affiché dans l'admin peut quand même être sur le disque et appelé par un override. Magento : `app/code` ou `vendor` plus un payment method activé en config. Les App Shopify malveillantes sont un autre monde : si votre vitrine PHP n'est qu'une façade, cherchez aussi là.

Les overrides PrestaShop (`override/`) sont l'endroit qu'on oublie après avoir « supprimé le module ». Le checkout passe encore par une classe copiée.

Ce qui reste après désactivation

Webhooks vers une URL inconnue, cron qui réactive le module, ligne dans `.htaccess` qui redirige `/commande` vers un autre hôte. Désactiver le plugin ne touche pas ces trois-là. Parcourez-les dans la même heure.

Les commandes fantômes créées pendant que le module était actif : exportez-les. Elles datent le préjudice, même à 0 €.

Un thème enfant qui hardcode un formulaire de carte dans `checkout.php` survit à tous les modules. Comparez ce fichier au thème d'origine.

• Webhooks PSP et CRM.
• Cron et mu-plugins.
• .htaccess et redirections checkout.
• Overrides et templates de thème.

Cartes, logs, obligation d'informer

Si le module envoyait les champs carte hors PCI, vous n'êtes plus sur un incident « plugin bizarre ». Vous êtes sur un skimmer. Le constat technique décide de l'information des personnes et, le cas échéant, de la CNIL. Ça vous incombe, pas au prestataire de nettoyage.

Ne promettez pas « aucune carte volée » dans un post LinkedIn le soir même. Vous n'avez pas encore les logs. Un message interne à l'équipe : module coupé, checkout fermé ou basculé, analyse en cours.

Gardez les logs d'accès et les logs PSP. Ils partent vite sur un mutualisé. Demandez-les à l'hébergeur le jour J, pas à J+15.

Refermer avant de réactiver le vrai module

Mots de passe panel, admin, FTP. Révocation des clés API. Recherche de webshell à la racine. Puis seulement, réinstallez le module officiel depuis le compte prestataire, pas depuis un zip posé sur le bureau depuis 2019.

Testez le checkout comme un client. Inspection d'URL Search Console sur la page paiement : le HTML doit être le vôtre, pas un formulaire tiers inconnu. Si Chrome a déjà classé le domaine, le réexamen Safe Browsing se dépose après cette page propre — délai souvent 24 à 72 h.

Vous pouvez déclarer la boutique si le module et le tunnel vous dépassent. Ne rouvrez pas le paiement « en attendant » avec le zip suspect encore dans `modules/`.