Over 200 PrestaShop stores expose installer, allowing full takeover

The affected stores span 27 countries, with France, Italy, Poland, and the Czech Republic accounting for the majority. Among them: a multi-billion dollar fashion retailer, two French university bookshops, and a pan-European retail chain with storefronts in five countries.

Sansec alerted each of the affected merchants.

How the attack works

PrestaShop ships with an install directory (/install/ in release builds, /install-dev/ in development builds) that contains the full installation wizard. When it remains accessible, an attacker can walk through the entire installer without any authentication.

In install-dev/controllers/http/process.php:

if (Tools::getValue('generateSettingsFile')) {
    $this->processGenerateSettingsFile();
}

This function writes app/config/parameters.php with database credentials from the installer session. Nothing prevents this from running on an already-installed shop. The ?step=process URL parameter lets an attacker force this step directly, bypassing step progression.

The installer accepts external MySQL credentials via dbServer, dbName, dbLogin, and dbPassword request parameters, so anyone can point the shop to an arbitrary database. From there, the installer populates a fresh PrestaShop instance with a new admin account.

PrestaShop does display a warning on the admin login page when the /install directory exists, replacing the login form with a message to delete it. However, this check only looks for /install, not /install-dev. And even when it does trigger, the gate only affects the rendered page: authentication itself can still be completed without the form being displayed.

Admin access leads to code execution: PrestaShop's module installer calls eval() on override files during module upload. After installing a webshell, the database config can be swapped back to the original credentials, giving access to all customer data.

Symfony Profiler exposure

Another 15 stores exposed the Symfony Profiler, which is enabled when PrestaShop runs in debug mode. The profiler is served under the admin path (/admin-dev/_profiler/ in development builds, /admin[random]/_profiler/ in production). Since production installs randomize the admin folder name, these are harder to discover, but the default /admin-dev/ path is trivially guessable.

The profiler records every request to the application, including requests from logged-in admin users. Each profiled request exposes its full session data, including the session cookie in plain text. It also exposes database credentials, application secrets, and internal routes.

PrestaShop's bug bounty is paused

PrestaShop has recently shut down their bug bounty program. The page now reads: "The program is currently paused. Please report security issues to security-core@prestashop.com instead."

While these findings are configuration errors rather than software vulnerabilities, the absence of an active bounty program leaves less incentive for researchers to report issues they find in the wild.

Recommendations

1. Delete the install directory: Remove /install-dev/ (and /install/) from your production server entirely.
2. Disable debug mode: Set _PS_MODE_DEV_ to false in config/defines.inc.php to disable the Symfony Profiler and other debug tools.
3. Scan for compromise: If your store had either of these directories exposed, run eComscan to check for backdoors, webshells, and other signs of compromise.

Read more

• PolyShell: unrestricted file upload in Magento and Adobe Commerce
• Digital skimmer hits global supermarket chain
• SessionReaper attacks have started, 3 in 5 stores still vulnerable
• SessionReaper, unauthenticated RCE in Magento & Adobe Commerce (CVE-2025-54236)
• ClickFix malware hits DoD cybersecurity vendor homepage