My back office behaves oddly when I open a customer message

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.

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.

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.