PrestaShop security: vulnerabilities (CVE), hack signs, what to do

Most store break-ins do not start with a sophisticated attack on the core, but with an old module that has a known hole. PrestaShop security rests on a few simple rules: an up-to-date core, modules and PHP, checking your installed modules against known vulnerabilities (CVE), separate accounts and strong passwords in the back office, correct file permissions and regular backups. Below you will find where to check for vulnerabilities, how to tell your store has been hacked, and what to do step by step after an attack.

How do PrestaShop stores get hacked?

An online store is an attractive target: customer data and payments pass through it, and many stores run for years without updates. The most common ways in:

• Vulnerable third-party modules. Usually an SQL injection in a module controller or AJAX script that can be called without logging in. The attacker then reads the database or writes their own code into it.
• An outdated PrestaShop core. Core vulnerabilities are rarer, but they are well documented and scanned for automatically. In July 2022 PrestaShop released version 1.7.8.7 to fix CVE-2022-36408, which had been used to plant fake payment forms in many stores.
• Weak or stolen passwords for the back office, FTP, SSH or the hosting panel.
• Leftovers: the install folder, database dumps in the public directory, old import scripts, uninstalled modules whose files are still on the server.

One thing many owners do not know: disabling or uninstalling a module does not remove its files. If the module has a standalone PHP script with a vulnerability, it can still be called from a browser. Delete unused modules from the disk.

PrestaShop vulnerabilities (CVE): where to check them?

Known vulnerabilities get CVE numbers and are published in a few places:

• Friends of Presta maintains a public list of security advisories, mostly for modules: security.friendsofpresta.org. Each entry gives the module name, affected versions, the fixed version (if there is one) and the CVE number.
• PrestaShop publishes advisories for the core in the project repository: github.com/PrestaShop/PrestaShop/security/advisories.

How to check your store:

1. In Modules → Module Manager, list the installed modules and their versions. Do not forget disabled ones.
2. Compare the list with the Friends of Presta advisories. Search by the module's technical name (its folder name in /modules), not its marketing name.
3. For vulnerable modules, install the fixed version from the author. If there is no fix or the author has disappeared, the module has to be removed, replaced or patched yourself.
4. Check the core version in Advanced Parameters → Information and compare it with the PrestaShop advisories.

Modules with obfuscated (encoded) code are a separate problem. They cannot be reviewed properly: neither you nor an auditor can see what they do or whether they hide a vulnerability. Our modules ship readable code with no DRM or obfuscation, so any developer can review it.

How to update PrestaShop safely?

Updates are the cheapest protection, and the one most often postponed. Look after three layers:

• The PrestaShop core. PrestaShop 1.6 has not received fixes for years, and the gap between 1.7 and versions 8 and 9 is large. If you stay on 1.7, at least install the latest release of that branch. We describe the migration path in How to upgrade PrestaShop, and if you would rather hand it over, we offer a fixed-price PrestaShop upgrade.
• Modules and theme. Check for updates from the authors, especially for payment, export and form modules, in other words anything that accepts data from visitors.
• PHP and the server. PHP 7.4 and 8.0 no longer receive security fixes. You can also see the PHP and database versions in Advanced Parameters → Information.

Before every update, back up files and database and test on a copy of the store.

The back office and employee accounts

The back office is the most valuable target, because it gives full control over the store.

• Admin folder name. The installer usually gives it a random name. Do not rename it to admin, panel or your store name.
• No install folder. It must not stay on the server after installation, and neither should old copies and ZIP archives of the store.
• Separate accounts. Every person gets their own account in Advanced Parameters → Team → Employees, with a profile and permissions limited to what they need. Disable an agency's or former employee's account as soon as the work ends.
• Strong, unique passwords and a password manager. In PrestaShop 8 and 9 you set the password policy in Advanced Parameters → Security, and Employee Sessions shows active sessions so you can delete suspicious ones.
• An extra barrier. Your host can usually restrict the admin folder to selected IP addresses or add a second, server-level password.
• API keys. In Advanced Parameters → Webservice, delete unused keys and give the rest only the permissions they need.
• Back office token protection should stay enabled.

File permissions and server configuration

Typical safe settings are 755 for folders and 644 for files, never 777. Configuration files holding the database password (app/config/parameters.php in PrestaShop 1.7 and later) should be readable only by the user the store runs as.

PrestaShop ships .htaccess files that, among other things, block access to anything other than images in the img folder. They only work on Apache, though. On nginx, the server administrator has to add equivalent rules, otherwise a PHP file uploaded through a vulnerability into the images folder will be executed.

In production, also turn off debug mode, directory listing and PHP error display to visitors, and keep database dumps outside the public directory.

How do you know your PrestaShop store has been hacked?

A break-in is rarely visible straight away. Typical signs:

• A payment skimmer. An extra card form appears at the payment step, or a script loads from an unknown domain. Often the first signal is customers reporting card fraud after buying from you.
• Unknown employees in Advanced Parameters → Team → Employees, or changed e-mail addresses on existing accounts.
• Modified files. New PHP files in img, upload, modules or the theme folder, a changed index.php, or files full of long base64_decode and eval strings.
• Spam. The server sends mass e-mails, pages with foreign keywords appear in Google, or visitors coming from search are redirected to other sites.
• Outside warnings. A security issues notice in Google Search Console, or a block from your payment provider or host.
• Sudden server load and suspicious entries in Advanced Parameters → Logs.

Quick core check: in Advanced Parameters → Information, the List of changed files section compares PrestaShop files with the originals for your version. It does not cover third-party modules or the theme, but it quickly reveals tampered core files.

What to do after your PrestaShop store has been hacked?

Work through the steps in order. Hastily deleting files often destroys the traces that show how the attacker got in.

1. Limit the damage. Turn on maintenance mode in Shop Parameters → General → Maintenance, or disable the affected payment method.
2. Preserve evidence. Copy the files, database and server logs as they are, before you change anything.
3. Change every password and key: employee accounts, database, FTP and SSH, hosting panel, store API keys and payment provider keys. Remove unknown accounts.
4. Find the entry point. Review the access logs (requests to modules just before the first changes), compare files with clean copies of the same version, and check your modules against the advisories.
5. Clean or restore the store. If you have a clean backup from before the infection, restore it and re-enter the missing orders. Without fixing the hole, the attack will soon repeat.
6. Patch and update. Remove vulnerable and unused modules, update the core, modules and PHP.
7. Inform your payment provider and host. Discuss whether you must report a personal data breach with a lawyer or your data protection officer.
8. Monitor files, accounts and logs over the following weeks, and request a review in Google Search Console.

If the store shows a blank page or a 500 error after the clean-up, see Blank page and error 500 in PrestaShop. For the future, set up automatic backups of the files and the database, stored outside the store's server.

PrestaShop security checklist: what to check and how often?

If you do not have time for this, our store security audit and fix covers checking the core and modules for CVEs, reviewing the server, back office and permissions, and fixing the vulnerable elements.

Frequently asked questions

Suspect a break-in, or want to check your store before something happens? Get in touch and we will tell you where to start.

Products in this article

Store security audit and fix

€1,499.00

Rated out of 5 stars based on () review(s)

Add to cart

Back to Blog