Quelles données de mes clients ont réellement pu partir

Deux familles de données, deux chemins de vol différents

La première erreur, quand on cherche ce qui a pu partir, consiste à tout mettre dans le même sac. Il faut séparer deux choses qui ne se volent pas de la même manière et ne se prouvent pas avec les mêmes traces.

D’un côté, les données déjà stockées : commandes, comptes clients, adresses de livraison et de facturation, historiques d’achat, contenus de fichiers de configuration. Elles se volent par un accès au serveur ou à la base, et laissent en général des traces exploitables : requêtes anormales, fichiers d’export apparus dans un dossier, pics de trafic sortant.

De l’autre, les données en transit : ce que le client tape en ce moment sur votre site, au premier rang desquelles les données de carte bancaire. Elles ne passent jamais par votre base si votre paiement est correctement délégué à un prestataire, et pourtant elles peuvent être volées, parce que le vol a lieu dans le navigateur du client avant même l’envoi. C’est le principe du vol de saisies par script, qui n’a besoin de toucher ni à votre base ni à vos sauvegardes.

Cette distinction n’est pas théorique : elle détermine où vous devez chercher, et ce que vous serez en mesure d’affirmer à la fin.

Remonter du point d’entrée vers le périmètre atteignable

La méthode qui donne des résultats consiste à partir du point d’entrée et à en déduire ce qui était atteignable, plutôt que de chercher au hasard des preuves de vol. Les incidents publiés ces derniers mois montrent que le périmètre varie énormément selon la porte utilisée.

Quand la porte est une extension piégée qui s’exécute côté serveur, le périmètre est très large. Dans la compromission de chaîne de distribution documentée en juin 2026 chez un éditeur d’extensions WordPress, la charge malveillante extrayait le contenu complet du fichier wp-config.php, les comptes administrateurs, les identifiants stockés par les extensions d’envoi d’e-mail, et les commandes WooCommerce des trois derniers mois. Ce dernier point est important : le voleur n’a pas pris toute la base, il a pris une fenêtre. Savoir laquelle change la réponse que vous devrez donner à vos clients.

Quand la porte est une exposition passive, le périmètre est plus étroit mais souvent plus ancien. L’avis publié en mai 2026 sur le module de transport upsshipping pour PrestaShop décrit un dossier de journaux accessible publiquement, dont les fichiers XML contenaient les identifiants d’API UPS, les numéros de compte expéditeur, ainsi que des noms, adresses postales et téléphones de clients. Sur un cas observé, ce dossier contenait plus de 2,3 millions de fichiers, environ 8,7 Go, couvrant de février 2023 à avril 2026. Ici il n’y a pas eu d’intrusion : les données étaient simplement lisibles, et elles l’étaient depuis trois ans.

Quand la porte est un point d’accès mal protégé qui renvoie un rapport technique, ce qui part n’est pas votre catalogue mais vos clés. La faille corrigée en mars 2026 dans l’extension d’envoi d’e-mails Gravity SMTP renvoyait environ 365 Ko de données contenant les clés d’API et jetons OAuth des services d’e-mail connectés, les informations de base de données, les versions de WordPress et de PHP, l’inventaire des extensions et le thème actif. Aucune donnée client dans ce lot, mais de quoi ouvrir plusieurs autres portes.

Enfin, quand la porte est un script inséré dans les pages, seules les données saisies pendant la période d’infection sont concernées, et elles ne sont nulle part sur votre serveur. C’est le cas du vol de données de carte par double formulaire décrit par Sansec en février 2026, et c’est aussi ce que faisait le JavaScript chargé depuis une valeur de configuration modifiée lors de la vague d’injections SQL signalée par PrestaShop en janvier 2025.

Le cas particulier des mots de passe clients

C’est la question qui revient systématiquement, et la réponse mérite d’être précise. Sur une installation PrestaShop ou WordPress à jour, les mots de passe clients ne sont pas stockés en clair : la base contient une empreinte calculée à sens unique. Une copie de la table des clients ne donne donc pas directement les mots de passe.

Cela réduit le risque, cela ne l’annule pas. Une empreinte peut être attaquée hors ligne, sans limite de tentatives et sans que vous le voyiez, et les mots de passe faibles tombent en premier. Surtout, le vrai risque n’est pas votre boutique : c’est la réutilisation. Un client qui utilise le même mot de passe sur sa messagerie voit le problème se déplacer ailleurs.

Il existe par ailleurs des scénarios où le mot de passe est capturé au moment de la saisie, donc en clair, sans passer par la base : c’est le même mécanisme que le vol de données de carte. Et il existe des scénarios où le compte est pris sans mot de passe du tout — la faille corrigée en octobre 2025 dans le module PrestaShop Checkout permettait une connexion silencieuse à un compte client à partir de son adresse e-mail. Dans ces deux cas, forcer une réinitialisation des mots de passe ne suffit pas : il faut avoir refermé la porte d’abord.