Mon back-office réagit bizarrement quand j’ouvre un message client

Un message qui s’exécute au lieu de s’afficher

Le scénario est toujours le même. Un visiteur envoie un message par le formulaire de contact de la boutique. Le message arrive dans la file du service client, en back-office. Quelqu’un l’ouvre pour y répondre, et la page fait ce qu’aucune page d’administration ne devrait faire : elle se recharge seule, une fenêtre s’ouvre, un champ se remplit, un enregistrement part sans qu’on ait cliqué.

Ce comportement porte un nom : une faille de script inter-sites stockée, souvent abrégée en XSS stockée. Deux mots comptent. Script inter-sites veut dire que du code écrit par quelqu’un d’autre s’exécute dans votre navigateur, à l’intérieur de votre site, avec exactement la même confiance que le code de votre boutique. Stockée veut dire que ce code n’est pas passé une seule fois par une adresse piégée : il a été enregistré en base de données, dans le contenu du message, et il se réexécutera à chaque fois qu’une personne ouvrira cette fiche.

PrestaShop a publié le 28 avril 2026 les versions 8.2.6 et 9.1.1 pour corriger exactement ce cas : une faille de script inter-sites stockée dans la vue Service client du back-office. L’avis correspondant est GHSA-w9f3-qc75-qgx9, classé CWE-79, de sévérité critique, avec un score de 9,3. Elle a été signalée de façon responsable par des chercheurs de Doyensec.

Le point d’entrée est public, la cible ne l’est pas

Le formulaire de contact est ouvert à tout le monde, sans compte et sans commande. C’est le point d’entrée. Ce n’est pas la cible. Un attaquant qui dépose du code dans un message ne gagne rien tant que personne ne l’ouvre : le message dort en base de données, inerte.

Il faut donc séparer deux choses que l’on confond presque toujours. Le message contient du code : c’est un fait passif, du texte enregistré, sans effet par lui-même. Le code s’exécute chez moi : c’est l’événement qui compte, et il se produit au moment où le back-office affiche ce texte sans l’avoir neutralisé. À cet instant, le code tourne dans le navigateur de la personne qui lit, sur le domaine de la boutique, à l’intérieur d’une session d’administration déjà authentifiée.

C’est cette session qui est le véritable objectif. L’attaquant n’a pas besoin de votre mot de passe. Il n’a pas besoin de passer votre double authentification. Il n’a pas besoin de connaître l’adresse de votre back-office autrement que par la page déjà chargée dans le navigateur. Il se sert de la session que vous venez d’ouvrir vous-même. Tout ce que cette session peut faire, le code peut le tenter : créer un compte employé, modifier une adresse de contact, changer une valeur de configuration, déclencher une action qui laissera un accès disponible longtemps après la fermeture de l’onglet.

Ce qu’il faut regarder sans ouvrir imprudemment

Le réflexe naturel — ouvrir le message pour voir ce qu’il contient — est précisément celui qu’il faut éviter tant que la boutique n’est pas corrigée. Tant que le correctif n’est pas appliqué, chaque ouverture est une exécution.

• Parcourez la liste du service client sans entrer dans les fils : l’objet, l’expéditeur et la date suffisent le plus souvent à repérer un envoi anormal.
• Un message dont l’objet ou l’extrait affiché contient des fragments qui ressemblent à du balisage, des guillemets en excès ou des caractères de ponctuation en série, doit être traité comme suspect.
• Une rafale de messages envoyés dans un intervalle court, sans rapport avec une commande, depuis des adresses jetables, est un signal en soi.
• S’il faut absolument lire le contenu, faites-le depuis la base de données ou une copie hors ligne, pas depuis l’interface d’administration.

Je ne conseille pas de supprimer les messages suspects avant d’en avoir figé une copie. Ce sont les seules pièces qui permettront ensuite de dater l’envoi, d’identifier qui l’a ouvert et de décider si l’incident a eu des conséquences.

Si des données clients ont été touchées

Une session d’administration détournée donne potentiellement accès à des données personnelles : fiches clients, adresses, historique de commandes, échanges du service client. Si l’examen des journaux montre qu’une consultation ou une extraction a eu lieu, vous n’êtes plus seulement face à un incident technique.

Le RGPD parle de violation de données dès qu’un incident de sécurité entraîne la destruction, la perte, l’altération ou la divulgation non autorisée de données personnelles, de manière accidentelle ou illicite. Toute violation doit être consignée dans un registre interne, y compris celles que vous ne notifiez pas. Si elle présente un risque pour les droits et libertés des personnes, elle doit être notifiée à la CNIL dans les 72 heures après en avoir pris connaissance. Si le risque est élevé, les personnes concernées doivent aussi être informées, avec des recommandations de protection concrètes. Si vous concluez à l’absence de risque, vous ne notifiez rien, mais vous devez pouvoir justifier cette analyse.