# My back office behaves oddly when I open a customer message

> A customer service page that reloads by itself, a window that opens, a field that fills in on its own: content sent by a visitor can run inside your own admin session, with your rights.

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

## Direct answer

> Stop opening that thread: until the fix is applied, every display of the message runs the code inside your own session. Note the subject, sender and date from the customer service list without entering the conversation. Then apply the update, after a full backup of files and database, and close any open admin sessions.

## A message that runs instead of displaying

The pattern is always the same. A visitor sends a message through the shop’s contact form. It lands in the customer service queue in the back office. Someone opens it to reply, and the page does what no admin page should ever do: it reloads on its own, a window opens, a field fills in, a record saves without a click.

This has a name: a stored cross-site scripting flaw, usually shortened to stored XSS. Two words matter. Cross-site scripting means code written by someone else runs in your browser, inside your site, with exactly the same trust as your shop’s own code. Stored means the code did not travel once through a booby-trapped link: it was saved to the database, inside the message body, and it runs again every time someone opens that record.

On 28 April 2026 PrestaShop released versions 8.2.6 and 9.1.1 to fix precisely this: a stored cross-site scripting flaw in the back office Customer Service view. The advisory is GHSA-w9f3-qc75-qgx9, classified CWE-79, critical severity, score 9.3. It was responsibly disclosed by researchers at Doyensec.

## What you see in the back office

- The Customer Service page reloads by itself when one particular message is opened.
- A window, an alert or a tab opens with no action on your part.
- A back office field fills in on its own, or a record saves without a click.
- The same behaviour repeats reliably on the same thread, and on no other.
- A member of staff reports odd behaviour you cannot reproduce from another session.
- Actions appear in the back office activity log at the times someone was reading customer service.

## The entry point is public, the target is not

The contact form is open to everyone, no account and no order needed. That is the entry point. It is not the target. An attacker who drops code into a message gains nothing until someone opens it: the message sits in the database, inert.

So two things need separating, and they are almost always confused. The message contains code is a passive fact — saved text, no effect of its own. The code runs on my machine is the event that matters, and it happens when the back office renders that text without neutralising it. At that point the code runs in the reader’s browser, on the shop’s domain, inside an admin session that is already authenticated.

That session is the real objective. The attacker needs no password from you. No two-factor step to get past. No knowledge of your back office address beyond the page already loaded in the browser. They use the session you just opened yourself. Anything that session can do, the code can attempt: create an employee account, change a contact address, alter a configuration value, trigger something that leaves access available long after the tab is closed.

## What to look at without opening anything carelessly

The natural reflex — open the message and see what is in it — is exactly the one to avoid until the shop is patched. Until the fix is applied, every opening is an execution.

Scan the customer service list without entering the threads: subject, sender and date are usually enough to spot an abnormal submission.

Treat as suspect any message whose subject or preview contains fragments that look like markup, stray quotes, or runs of punctuation.

A burst of messages sent in a short window from disposable addresses, unrelated to any order, is a signal in itself.

If the content really must be read, read it from the database or an offline copy, not from the admin interface.

I would not delete suspect messages before freezing a copy. They are the only evidence that will let you date the submission, identify who opened it, and decide whether the incident had consequences.

## The three routes to a fix, in order of preference

1. **Back up first, no exceptions** — PrestaShop’s official recommendation is explicit: a full backup of files and database before any update. A backup taken afterwards is worthless if it already contains the problem.
2. **Move to a fixed version** — This is the preferred route. Versions 8.2.6 and 9.1.1, released on 28 April 2026, fix the flaw. PrestaShop explicitly recommends updating to 8.2.6 for shops still on that branch.
3. **Apply the hotfix module** — For a shop that cannot move version straight away, PrestaShop provides a dedicated hotfix module, pshotfix_ghsaw9f3qc75qgx9. It is a valid stopgap, not a substitute for updating.
4. **Patch the files by hand** — The third route is to apply the correction manually to the affected template and validation files. It is the most fragile: it will be overwritten by the next update and it assumes you know exactly what you are changing.
5. **Then check what could have been done with your rights** — Once the flaw is closed: the list of employee accounts and their profiles, admin sessions still active, back office login logs, and any account created or modified since the first suspect message was opened.

## A restricted employee account is no protection here

> I am often told that customer service is handled by a limited profile, so the risk must be low. That reasoning does not hold. The code does not run with rights of its choosing: it runs with those of the session open at the moment of display. If the person opening the message holds the rights for an action, the code can attempt that action. And nothing stops a message from sitting in the queue until a full administrator eventually opens it. Restricting rights is still worth doing, but it narrows the blast radius rather than removing the exposure.

## If customer data was touched

A hijacked admin session potentially reaches personal data: customer records, addresses, order history, customer service threads. If the logs show that data was viewed or extracted, this is no longer only a technical incident.

Under the GDPR, a personal data breach is any security incident leading to the accidental or unlawful destruction, loss, alteration or unauthorised disclosure of personal data. Every breach has to be entered in an internal register, including those you do not report. If it presents a risk to people’s rights and freedoms, it must be notified to the supervisory authority — the CNIL in France — within 72 hours of becoming aware of it. If the risk is high, the individuals concerned must also be told, with concrete protective advice. If you conclude there is no risk, you notify nobody, but you must be able to justify that assessment.

## Related reading

- **Backing up the shop before any work** — The one step never to skip before a security update. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Checking whether my site is compromised** — What to examine when odd behaviour might be more than a bug. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Admin passwords and shared access** — How to limit what a hijacked admin session can reach. ([/securite/mots-de-passe-administration-acces-partages](/securite/mots-de-passe-administration-acces-partages))
- **Tracking flaws that affect your store** — Where to follow advisories so you don’t learn of a flaw from the symptom. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))

## FAQ

### Is a booby-trapped message dangerous while nobody opens it?

No. Sitting in the database it has no effect. The risk starts when the back office renders it. That is why the first measure is to stop opening suspect threads, even before the update.

### My shop is on 8.2 — do I have to move to 9 to be safe?

No. 8.2.6 fixes the flaw and PrestaShop explicitly recommends that update. The 8.2.x branch is in extended support: it only receives security fixes and critical corrections, which is enough here.

### Does the hotfix module replace the update?

It closes the flaw without changing version, which helps when an update needs preparation. I treat it as a stopgap: the shop stays on a version that has not received the other fixes published since.

### How do I know whether anyone actually opened the message?

Through back office login logs and employee activity history, cross-checked against the date the message arrived. Without those logs, or if retention is too short, the question can stay unanswered.

### Should I close every admin session?

Yes, that is a reasonable step after patching, along with changing employee passwords. A session opened before the fix is a session whose use you cannot account for.