My PrestaShop store was hacked and no password ever leaked

The question of who got your password often doesn’t apply

When a store is compromised, the first instinct is to look for a stolen credential: a former contractor still holding access, an infected workstation, a password reused elsewhere. That is a legitimate lead, and sometimes the right one. But several of the flaws published in the PrestaShop ecosystem in recent years require none of that. They are triggered from outside, on a public page of the shop, with no account, no session and no action on your part.

This is called unauthenticated exploitation. The server receives a request that looks like an ordinary visit, except that one of the submitted values is crafted to trigger behaviour the module’s author never anticipated. The module treats it as normal working data; depending on the flaw, it ends in a diverted database query, or in code running on the server. No password is ever involved. Changing every credential afterwards therefore closes nothing: the door was never held shut by a credential.

A second common misreading: my back office is locked down, access is restricted. Locking down the back office remains good practice, but these flaws never touch it. They go through the shop itself, the part you deliberately keep open to every visitor. Nor is this new: on 22 January 2025 PrestaShop already issued an official alert about a wave of attacks exploiting SQL injection flaws in third-party modules rather than in the core.

Two public surfaces: a filter page and a promotional pop-up

On 3 June 2026 PrestaShop published security advisory GHSA-m5f5-28qr-9g9r, referenced as CVE-2026-54159, covering the official faceted navigation module ps_facetedsearch: the one that renders price, brand and feature filters on your category pages. The CVSS score is 10.0, the top of the scale. Versions 3.0.0 to 4.0.3 are affected; the fixed release is 4.0.4.

The cause is unsafe deserialisation of cached filter data: the price and weight slider values, which travel through the URL, were serialised and then read back with unserialize(). The result is PHP object injection, and from there remote code execution. The advisory states that exploitation is possible remotely, with no account and no authentication, in a single request, and can lead to full server compromise. The flaw was found by Frédéric Moreau (Antadis) and Gilles Caudal (Datalinx).

The next day, on 4 June 2026, PrestaShop released versions 9.1.4 and 8.2.7. They change nothing in the core and alter no behaviour: they simply ship ps_facetedsearch 4.0.4 so that a fresh install starts with the fixed module (9.1.4 also updates dependencies, Symfony 6.4.41 and Twig 3.27.1). On a store that is already installed, what matters is the module version, not the core version. Plenty of merchants check the latter and draw the wrong conclusion.

The second example is a third-party promotional pop-up module, advancedpopupcreator, published by Idnovate. The advisory of 16 February 2026, CVE-2025-69633, CVSS 9.8, describes an SQL injection exploitable without authentication in every version before 1.2.7; the fix is 1.2.7, and the advisory recommends removing the module if it is no longer used. The detail that matters to you lies elsewhere: attempts appear in the site logs as plain POST / requests. Without a dedicated tool, nothing sets them apart from ordinary traffic. That is precisely why many merchants find no trace of an intrusion and fall back on the stolen password theory.