Un client s’est retrouvé connecté sur le compte d’un autre

Trois causes, un seul symptôme

Le signalement arrive presque toujours dans les mêmes termes : un client voit dans son espace des commandes qui ne sont pas les siennes, ou vous recevez une réclamation pour une adresse de livraison que personne n’a jamais saisie. Le premier réflexe, y compris le mien pendant longtemps, est de penser au cache. C’est parfois le cache. Ce n’est pas toujours le cache, et la différence change complètement ce qu’il faut faire ensuite.

Trois causes distinctes produisent ce même symptôme.

• Un cache mal configuré. Une page personnalisée — un en-tête avec un prénom, un panier, un bloc de compte — a été mise en cache pendant la visite d’un client, puis servie telle quelle à un autre visiteur. Le contenu affiché est faux, mais la session, elle, reste la bonne.
• Une session partagée. Deux personnes utilisent le même navigateur sur le même poste : ordinateur familial, poste d’accueil, tablette en magasin. La session ouverte n’a simplement jamais été fermée.
• Un véritable défaut d’authentification. Le serveur a réellement associé la session au mauvais compte. Ce n’est plus un problème d’affichage : c’est une prise de contrôle de compte.

Quand c’est bien un défaut d’authentification

Le tunnel de commande est l’endroit où ce type de défaut apparaît le plus souvent, et le paiement express en est le point le plus sensible. Un paiement express a précisément pour but de supprimer des étapes : le client arrive depuis un bouton, le moyen de paiement fournit une identité, et la boutique doit décider en une fraction de seconde à quel compte rattacher cette commande. Chaque étape supprimée est une vérification qu’il faut refaire ailleurs, correctement.

Le module de paiement officiel de PrestaShop, ps_checkout, a été concerné par ce cas. Une validation manquante sur la fonctionnalité Express Checkout permettait une connexion silencieuse, et donc la prise de contrôle d’un compte client à partir de son adresse e-mail. La faille porte l’identifiant CVE-2025-61922, avec un score CVSS de 9,1 : exploitable par le réseau, complexité d’attaque faible, aucun privilège requis, aucune interaction de l’utilisateur. Les correctifs ont été publiés le 16 octobre 2025, en versions 4.4.1 et 5.0.5.

L’expression « connexion silencieuse » mérite d’être traduite concrètement. La boutique ouvre une session au nom d’un client sans que ce client ait saisi son mot de passe et sans qu’il en soit averti. De son côté, rien ne se passe : pas d’e-mail, pas de demande de confirmation, aucune trace visible dans son espace. C’est ce silence qui rend le problème long à détecter. Il n’y a pas de tentative ratée, pas de série d’échecs de connexion à repérer, juste une session de plus qui, vue de loin, a l’air parfaitement normale.

Ce qu’un compte client contient réellement

On sous-estime souvent ce qu’un compte client donne à qui y entre. Ce n’est pas seulement un historique.

• L’historique complet des commandes : ce qui a été acheté, quand, pour quel montant, livré à quelle adresse.
• Le carnet d’adresses : adresses postales, numéros de téléphone, parfois une adresse professionnelle et un nom d’entreprise.
• Les données de contact, directement réutilisables pour un hameçonnage crédible auprès de ce client, puisqu’elles permettent de citer une vraie commande.
• La possibilité de passer une commande depuis le compte usurpé, avec les moyens de paiement enregistrés côté prestataire lorsqu’il en existe.

Sur ce dernier point je reste prudent, et vous devriez l’être aussi. Ce qui est réellement réutilisable dépend entièrement du prestataire de paiement et de la façon dont l’enregistrement du moyen de paiement est implémenté. La boutique ne stocke normalement pas le numéro de carte. Ce que je peux affirmer sans journaux, c’est ce qui était possible ; ce qui a été effectivement fait, non.

Ce que les journaux disent, et ce qu’ils ne diront pas

L’avis publié pour cette faille recommande de mettre à jour sans délai, de relire les journaux d’authentification, de prévenir les clients potentiellement concernés, et de surveiller les commandes et les créations de comptes atypiques. Concrètement, voici ce que je cherche.

• Des connexions réussies qui n’ont été précédées d’aucune soumission de formulaire de connexion.
• Des connexions sur un même compte depuis deux contextes très éloignés dans un intervalle court.
• Des commandes passées immédiatement après une connexion de ce type.
• Des changements d’adresse e-mail, de mot de passe ou d’adresse de livraison suivis d’une commande.
• Des créations de comptes en rafale, ou construites sur un même motif d’adresse.

Et voici ce que je ne peux pas savoir sans ces journaux : combien de comptes ont été touchés, si un seul client a été visé ou si la boutique a été balayée méthodiquement, à partir de quelle date exactement, et si l’accès a servi à autre chose qu’à passer une commande. Une durée de conservation trop courte côté hébergeur peut rendre ces questions définitivement sans réponse. C’est un point à vérifier avant d’avoir à s’en servir, pas le jour où un client appelle.