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

> Une page du service client qui se recharge seule, une fenêtre qui s’ouvre, un champ qui se remplit : le contenu d’un message envoyé par un visiteur peut s’exécuter dans votre propre session d’administration, avec vos droits.

- Source canonique : [https://allaux.fr/securite/back-office-reagit-a-l-ouverture-d-un-message-client](https://allaux.fr/securite/back-office-reagit-a-l-ouverture-d-un-message-client)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Cessez d’ouvrir le fil concerné : tant que le correctif n’est pas appliqué, chaque affichage du message exécute le code dans votre session. Relevez l’objet, l’expéditeur et la date depuis la liste du service client, sans entrer dans la discussion. Appliquez ensuite la mise à jour, après sauvegarde complète des fichiers et de la base, puis déconnectez les sessions d’administration ouvertes.

## 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.

## Ce que vous voyez côté back-office

- La page Service client se recharge d’elle-même à l’ouverture d’un message précis.
- Une fenêtre, une alerte ou un onglet s’ouvre sans aucune action de votre part.
- Un champ du back-office se remplit tout seul, ou un enregistrement part sans clic.
- Le même comportement se reproduit systématiquement sur le même fil de discussion, et sur aucun autre.
- Un employé signale un affichage anormal que vous ne reproduisez pas depuis une autre session.
- Des actions apparaissent dans l’historique du back-office aux heures où quelqu’un consultait le service client.

## 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.

## Les trois voies de correction, par ordre de préférence

1. **Sauvegarder d’abord, sans exception** — La recommandation officielle de PrestaShop est explicite : sauvegarde complète des fichiers et de la base avant toute mise à jour. Une sauvegarde prise après coup ne vous sert à rien si elle contient déjà le problème.
2. **Monter de version** — C’est la voie à privilégier. Les versions 8.2.6 et 9.1.1, publiées le 28 avril 2026, corrigent la faille. PrestaShop recommande explicitement la mise à jour vers la 8.2.6 pour les boutiques restées sur cette branche.
3. **Appliquer le module de correctif** — Pour une boutique qui ne peut pas monter de version tout de suite, PrestaShop met à disposition un module de correctif dédié, pshotfix_ghsaw9f3qc75qgx9. C’est une solution d’attente valable, pas une dispense de mise à jour.
4. **Corriger les fichiers à la main** — La troisième voie consiste à appliquer manuellement la correction sur les fichiers de gabarit et de validation concernés. C’est la plus fragile : elle sera écrasée à la prochaine mise à jour et elle suppose de savoir exactement ce que l’on modifie.
5. **Vérifier ensuite ce qui a pu être fait avec vos droits** — Une fois la faille fermée : liste des comptes employés et de leurs profils, sessions d’administration encore actives, journaux de connexion au back-office, et toute création ou modification de compte survenue depuis la première ouverture d’un message suspect.

## Un employé aux droits limités ne protège pas de cette faille

> On me répond souvent que le service client est confié à un profil restreint, donc que le risque est faible. Ce raisonnement ne tient pas ici. Le code ne s’exécute pas avec les droits qu’il choisit : il s’exécute avec ceux de la session ouverte au moment de l’affichage. Si la personne qui ouvre le message dispose des droits nécessaires pour une action, le code peut tenter cette action. Et rien n’empêche un message d’attendre en file jusqu’à ce qu’un administrateur complet finisse par l’ouvrir. Restreindre les droits reste utile, mais cela réduit la portée : cela ne supprime pas l’exposition.

## 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.

## Pour aller plus loin

- **Sauvegarder la boutique avant intervention** — La seule étape à ne jamais sauter avant une mise à jour de sécurité. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Vérifier si mon site est compromis** — Ce qu’il faut examiner quand un comportement anormal peut être plus qu’un bug. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Mots de passe d’administration et accès partagés** — Comment limiter la portée d’une session d’administration détournée. ([/securite/mots-de-passe-administration-acces-partages](/securite/mots-de-passe-administration-acces-partages))
- **Surveiller les failles qui concernent ma boutique** — Où suivre les avis de sécurité pour ne pas découvrir la faille par le symptôme. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))

## FAQ

### Un message piégé est-il dangereux tant que personne ne l’ouvre ?

Non, tant qu’il reste en base de données il n’a aucun effet. Le risque commence au moment où le back-office l’affiche. C’est pour cette raison que la première mesure est d’arrêter d’ouvrir les fils suspects, avant même la mise à jour.

### Ma boutique est en 8.2, dois-je passer en 9 pour être corrigé ?

Non. La 8.2.6 corrige la faille et PrestaShop recommande explicitement cette mise à jour. La branche 8.2.x est en support étendu : elle ne reçoit plus que des correctifs de sécurité et des corrections critiques, ce qui reste suffisant ici.

### Le module de correctif remplace-t-il la mise à jour ?

Il ferme la faille sans changer de version, ce qui est utile quand une mise à jour demande une préparation. Je le considère comme une mesure d’attente : la boutique reste sur une version qui n’a pas reçu les autres correctifs publiés depuis.

### Comment savoir si quelqu’un a réellement ouvert le message ?

Par les journaux de connexion au back-office et l’historique d’activité des employés, croisés avec la date d’arrivée du message. Sans ces journaux, ou s’ils sont conservés trop peu de temps, la question peut rester sans réponse.

### Faut-il fermer toutes les sessions d’administration ?

Oui, c’est une mesure raisonnable après correction, en même temps que le changement des mots de passe employés. Une session ouverte avant le correctif reste une session dont vous ne savez pas ce qu’elle a servi à faire.