How to check if your PrestaShop modules are vulnerable

Modules are the part of a PrestaShop store that changes the most: each one has its own vendor, its own update pace and its own flaws. Once a flaw is discovered and published, bots quickly start looking for stores that still run the affected version. Knowing where you stand is the foundation of any security effort.

What a published vulnerability is

A known vulnerability usually gets a CVE identifier, in the form “CVE-year-number”. The entry names the affected component, the affected versions, the version that fixes the issue and a CVSS severity score from 0 to 10.

For a merchant, three things matter:

• the module and the affected versions: does your version fall within the range?
• the severity: SQL injection or remote code execution comes before a display glitch;
• the fix: is there a fixed version, and is it available for your version of PrestaShop?

The manual method, step by step

1. List your modules

In PrestaShop’s module manager, write down the technical name, version and vendor of every installed module. Do not forget disabled modules: their files stay on the server and may still be exploitable. Do the same for the PrestaShop version itself.

2. Check the sources of vulnerabilities

For each module, look for published flaws in:

1. public CVE databases, searching for the module’s technical name;
2. security advisories published by the PrestaShop community, including those from the Friends of Presta association;
3. the vendor’s changelog and the module’s PrestaShop Addons page, which sometimes mention a “security fix” without a CVE number.

3. Compare versions

If your version is equal to or lower than the last affected version, the module is vulnerable. If the entry does not say which version fixes the issue, contact the vendor before drawing conclusions.

4. Repeat regularly

New flaws are published all the time. A check is only valid on the day it was done: repeat it after every module install or update, and at least once a month.

This method works, but it gets long once a store has dozens of modules, and it is easy for one to slip through the cracks.

Automate the check with a scanner

A vulnerability scanner runs the same comparison for you. Sentinel’s vulnerability scanner analyses PrestaShop itself and the installed modules, then ranks the flaws it finds by severity (critical, high, medium, low) with their CVE reference, CVSS score, affected versions and links to the sources.

• It only sends the versions of PrestaShop, PHP and your modules: no customer or order data.
• You keep a history of your scans and can export a report as CSV, JSON or TXT.
• If you fixed a flaw by other means than an update, you can mark it as fixed.

In the free version, Sentinel allows one scan every 24 hours and covers vulnerabilities published more than 30 days ago. The Pro version removes the scan limit, includes the most recent vulnerabilities, even those published the same day, and can run an automatic scan every day with a report by email.

What to do when a module is vulnerable

Deal with critical and high-severity flaws first.

1. Update the module if a fixed version exists. Take a backup first, then check that the store still works.
2. If there is no fix, disable the module, then uninstall it and delete its files if you can do without it. Ask the vendor when a fix is expected.
3. If the module is essential and has no fix, get a developer to apply a patch or a workaround. A web application firewall can block known exploit attempts in the meantime: that is the job of Sentinel Pro’s web application firewall, whose signatures are updated without waiting for a new module release.
4. Update PrestaShop if the flaw affects PrestaShop itself.
5. Run a new scan to confirm the flaw no longer shows up.

A fixed flaw may have been exploited before

Updating a module closes the door, but tells you nothing about what may have come in before. If a module stayed on a vulnerable version for a long time, look for signs of intrusion:

• employee accounts you do not recognise;
• unknown or modified PHP files in the module, theme or image folders;
• unusual requests to that module in the server logs.

Sentinel Pro’s file integrity check compares PrestaShop, module and theme files with their reference versions and flags modified, missing or unexpected files, with a line-by-line comparison. If you find signs of compromise, follow our guide PrestaShop store hacked: what to do.

Good habits

• Only install modules whose vendor publishes updates.
• Remove what you no longer use.
• Keep a written list of your modules and their vendors.
• Check for vulnerabilities after every change, and at least once a month.

To protect access to your administration too, see our guide How to secure the PrestaShop back office. Sentinel Free installs in a few minutes; the differences between Free and Pro are on the pricing page.