ps_facetedsearch vulnerability: the PrestaShop update you cannot skip

A 10-out-of-10 score, exploitable without an account

On 3 June 2026, the PrestaShop team released an emergency patch for ps_facetedsearch, the faceted search module installed by default on virtually every store since version 1.7.1.0. The ps_facetedsearch vulnerability it closes carries the highest score on the CVSS scale: 10.0.

Three things make it so dangerous:

• it requires no authentication: no customer account, no back office access;
• it is exploited from the front office, with nothing more than an HTTP request;
• it leads to remote code execution, meaning an attacker-controlled PHP file dropped on your server.

In practice, a bot scanning PrestaShop stores can take control of yours without a single line appearing in your admin history.

How the vulnerability works

The module caches its filter blocks so it does not have to recalculate the facets on every visit. The values of the slider filters (price, weight) are read from the URL, then stored in that cache in serialised form.

The trouble starts when they are read back. Up to version 4.0.3, the module passed those values straight to PHP's native unserialize() function without validating them properly beforehand. An attacker can therefore craft a URL containing a malicious PHP object. On deserialisation, that object triggers a gadget chain present in PrestaShop's dependencies and ends up writing an arbitrary file into the module's own directory.

The official fix replaces unserialize() with \Tools::unSerialize(), PrestaShop's hardened wrapper.

Are you affected?

Vulnerable versions: 3.0.0 to 4.0.3. Fixed version: 4.0.4.

Check your version under Modules > Module Manager, searching for "Faceted search". You can also read the <version> tag in modules/ps_facetedsearch/config.xml.

In the database, one query is enough:

SELECT name, version FROM ps_module WHERE name = 'ps_facetedsearch';

Anything below 4.0.4 should be treated as exposed, even if the filters are only displayed on a handful of categories: the controller is still reachable.

The fix: two possible routes

Update the core. PrestaShop released versions 8.2.7 and 9.1.4 the same day, both shipping the patched module. This is the recommended route if you are already close to those versions.

Update the module only. Download ps_facetedsearch 4.0.4 from the official repository and replace the folder. This is the quicker option when a core upgrade means a full round of testing.

Either way, empty var/cache/prod/ afterwards and clear the module's own cache. If you cannot act straight away, apply the workarounds published with the advisory: remove the slider filters from your public templates, clear the faceted search cache, and block, at web application firewall level, any request whose query string contains PHP serialisation patterns (O:, ;i:).

Checking whether the store has already been visited

A patch does not close a door that has already been used. Once you have updated, look for signs that a file was dropped.

Recently modified PHP files in the modules:

find modules/ -name "*.php" -mtime -60 -ls

Typical backdoor patterns:

grep -rl "eval(\$_POST\|eval(base64_decode\|assert(\$_REQUEST" modules/ themes/ override/

Also check:

• the modules/ps_facetedsearch/ directory: any .php file that is not part of the official distribution is suspect;
• your host's access logs, looking for requests containing abnormally long strings;
• the ps_employee table: an admin account you do not recognise points to a compromise built to last;
• the .htaccess and robots.txt files, frequently altered to hide spam pages.

If you find something, do not simply delete the file. An intrusion almost always comes with a second backdoor. You need to change every employee password, regenerate the keys in config/settings.inc.php including _COOKIE_KEY_, and restore from a backup taken before the intrusion. Our article on a hacked PrestaShop store sets out the full procedure.

The lesson: a default module is not a safe module

Plenty of merchants keep a close eye on their third-party modules and let the native ones look after themselves. This episode is a reminder that code shipped by default runs on hundreds of thousands of stores, which is precisely what makes it worth an attacker's time.

Three habits cut the risk dramatically:

• follow the security advisories published by PrestaShop and Friends-of-Presta;
• apply security patches within 72 hours, going through a staging environment when the store is complex;
• keep an inventory of your module versions, so that "am I affected?" takes five minutes to answer.

That is exactly what a PrestaShop maintenance contract covers.

Need an audit right now?

We check your version, apply the patch and look for traces of intrusion. Free diagnosis, reply within 1 hour, 9am to 10pm, 7 days a week.