Vulnerable PrestaShop modules: known CVEs and fixed versions

How to read this list

Each row gives the module's technical name (the name of its folder in modules/, which is what you should look for), its commercial name, the CVE identifier linked to the advisory, the affected versions, the version that fixes it and the published severity (CVSS 3.1 score, 0 to 10). I flag the cases where the advisory says the flaw has been used in real attacks, mostly to install skimmers that steal credit cards.

The main source is the advisory database of Friends of Presta, the non-profit association that coordinates security for the PrestaShop ecosystem, cross-checked with each CVE's record in the NVD. It is not a complete list: Friends of Presta publishes hundreds of advisories, and here I collect the ones for payment, checkout, blog, cookie and theme modules that I run into most often in the stores I check.

Modules with published flaws

Payment and checkout

Popups, cookies and page builders

Blogs, menus and themes

Quotes, shipping and native modules

Two advisories carry a special note: for simpleimportproduct, Friends of Presta considers that the fix still leaves a high risk and recommends considering removing the module; and for jmsmegamenu no fixed version has been published, so the only safe way out is to remove or replace it.

PrestaShop core

The core has flaws too, although they are fixed and disclosed in an orderly way in the security advisories of the official repository. The most relevant ones when deciding whether to upgrade:

• CVE-2022-31181 · from 1.6.0.10 · fixed in 1.7.8.7 · Critical (9.8). SQL injection chained with the Smarty cache stored in MySQL to execute code; this is the 2022 campaign that left a blm.php in the root folder and a fake payment form. It is sometimes cited as CVE-2022-36408, an identifier rejected as a duplicate.
• CVE-2023-30839 · fixed in 8.0.4 and 1.7.8.9 · Critical. A back-office employee could write to the database through the SQL manager without having permission to do so.
• CVE-2023-39528 and CVE-2023-39526 · fixed in 8.1.1 (and the second one also in 8.0.5 and 1.7.8.10) · Critical. Reading server files and possible code execution from the back office.
• CVE-2024-34716 · 8.1.0 to 8.1.5 · fixed in 8.1.6 · Critical. XSS through the contact form with an attached file.
• CVE-2026-44212 · fixed in 8.2.6 and 9.1.1 · Critical. Stored XSS that runs in the back-office customer service view.
• August 2026: five advisories (SQL injection in back-office filters, SSRF in CSV import, IP spoofing with X-Forwarded-For, customer data exposure in notifications and formula injection in CSV exports), fixed in 8.2.8 and 9.1.5.

Official modules. Not everything comes from third parties: in June 2026 a critical flaw (10 out of 10) was published in ps_facetedsearch, the official catalog filter module that ships with almost every 1.7, 8 and 9 store. It affects 3.0.0 to 4.0.3 and is fixed in 4.0.4. How to check your version and what to do if you cannot update: ps_facetedsearch (CVE-2026-54159).

If you are on 1.7, none of the flaws discovered from now on will get a patch: the branch stopped being maintained when PrestaShop 9.0 came out. How to make the jump: upgrade PrestaShop.

How to check your store

1. Get the list of modules and versions

In the back office, Modules → Module Manager shows each module with its version. Faster, from the database (replace ps_ with your prefix):

SELECT name, version, active FROM ps_module ORDER BY name;

Careful: this table stores the version registered at install time. If someone uploaded new files over FTP without going through the module manager, the real version is in the module's main file (modules/name/name.php, on the $this->version line).

2. Look for the ones that do not show up

A module that was uninstalled but whose files are still in modules/ does not appear in the module manager and can still be attacked, because its scripts respond just the same. Compare the list of folders with the one in the database:

ls modules/ > folders.txt
# compare with the name column of ps_module: anything only in folders.txt needs checking

3. Cross-check with the advisories

Search for each technical name on security.friendsofpresta.org and in the NVD. If you have an affected version: update to the fixed one, and if there is no fix or the author no longer supports it, remove the module and its files.

4. If a module was affected, check whether someone already got in

Updating closes the door, but it does not throw out whoever is already inside. If you had a vulnerable version with an exploitation warning, check the store as if it were hacked: modified files, overrides, configuration and checkout. The steps are in what to do if your PrestaShop is hacked.

The read-only connector does this cross-check automatically: it reads the real list of modules and versions from inside the store, compares it with the published advisories and checks core integrity, without being able to change anything. From the outside, the free scan detects the modules that are publicly visible. If you want someone to do it for you, the PrestaShop security audit checks every module, inactive ones included, at a fixed price; if a module has already been exploited, go straight to hacked PrestaShop repair.

If the author does not fix the flaw

It happens more than you would think: abandoned modules, authors who do not reply, or themes bought years ago from a vendor that no longer exists. In those cases there are three real options, in order of preference:

1. Replace the module with a maintained one that does the same job, or with a native PrestaShop module if it covers the feature.
2. Remove it if the feature is not essential. Delete the whole folder from modules/; uninstalling is not enough.
3. Fix it yourself or have your developer fix it, if you have the code: Friends of Presta advisories usually explain which method or parameter is vulnerable, and sometimes include the patch. It is your own fix, and you will have to maintain it with every update.

A web application firewall (WAF) can stop some of the attacks while you decide, but several advisories warn that there are variants of the attack designed to get around it. Use it as a stopgap, not as the solution.

Sources

• Friends of Presta: security advisories (each row links to its advisory).
• NVD, National Vulnerability Database from NIST, for the description and score of each CVE.
• PrestaShop core security advisories on GitHub.
• PrestaShop's notice about the July 2022 campaign.