PrestaShop module security: the attack vector that compromises online shops most
By Kike Gandia · Co-Founder & CEO, OSCP
Third-party modules in PrestaShop are the equivalent of WordPress plugins: third-party PHP code executed with full privileges over the installation. The difference is that the PrestaShop module ecosystem has a track record of critical vulnerabilities with active public exploits that have compromised thousands of shops, many without their owners ever knowing.
The most common vulnerabilities in PrestaShop modules
SQL Injection: The most frequent pattern in PrestaShop modules with a CVE history. Modules that accept user input and pass it directly to database queries without sanitisation are exploitable to extract customer data, credentials or order information.
Stored XSS in the back office: Modules that allow an unauthenticated attacker (or one with low privileges) to inject JavaScript into the admin panel, compromising the session of any administrator.
File upload without validation: Import modules, product customisers or document managers that allow PHP files to be uploaded disguised as images or documents.
Unauthenticated controller endpoints: Many modules register controllers accessible via URL that execute administrative actions without checking whether the user is authenticated.
Modules with a history of active vulnerabilities
PrestaShop has a documented history of critical vulnerabilities in widely used modules: payment modules, product import modules, newsletter modules and customisation modules. In several cases the exploits were public for weeks before the authors released patches, and many shops are still running vulnerable versions months later.
Systematically reviewing installed modules against CVE databases (Friends of Presta, NVD) is the first step of any PrestaShop security audit.
Custom modules and bespoke development
Modules developed bespoke for specific integrations —ERP, CRM, local payment gateways, data exporters— have rarely undergone a security code review. They are PHP code running in production with full access to the database and the file system, without any security quality guarantee.
Auditing custom modules includes static code analysis searching for insecure patterns and penetration testing against the endpoints they expose.
How to decide whether a module gets patched, replaced or removed
An inventory with CVEs is worth nothing if nobody then decides what to do with each line. These are the reasonable decisions by situation.
| Situation | Reasonable decision | Why |
|---|---|---|
| The author has released a patch | Update and verify in staging before production | The shortest route and the only one that closes the flaw at the root |
| Unsupported module with a public exploit | Replace with a maintained alternative | With no active author, no patch is coming |
| Module no longer used but still installed | Uninstall and delete from disk | A disabled module can still serve its controllers if the files remain |
| The flaw is in a custom module of yours | Fix it and review the rest of the module | Insecure patterns rarely appear only once in the same codebase |
| Business-critical module with no alternative | Isolate: a specific WAF rule and a code review | Buys time while a replacement is found; it does not replace one |
The row that surprises people most is the third: disabling a module from the back office does not always stop its files from remaining reachable by URL. If it is not used, delete it.
Signs the shop is already compromised
In a share of PrestaShop audits the finding is not a vulnerability waiting to be exploited, but one that was exploited months ago. These are the signs worth checking before anything else.
- New PHP files inside /modules/ or /override/ that match no deployment.
- Core class overrides nobody on the team remembers creating.
- Employees with an administrator profile created outside the usual process, or with creation dates that do not add up.
- Scheduled tasks or crons added that invoke custom scripts.
- Files with recent modification dates when no deployment happened on that date.
- Unexpected scripts loading in the checkout template or the footer.
- Customer accounts with inconsistent permissions or orders.
If any of these appear, the right order is to preserve evidence first and clean up afterwards: if the trail is deleted before the entry path is established, reinfection is a matter of weeks.
FAQ
How do I know if any of my current modules has an active vulnerability?
The most reliable approach is a systematic analysis of every installed module against up-to-date CVE databases. There are also continuous monitoring services that alert you when a vulnerability is published for an installed module.
Are modules from the official PrestaShop marketplace more secure?
They have basic review controls, but they still have a history of vulnerabilities. Marketplace validation is not equivalent to a security audit. Modules with thousands of installations and years of activity have had critical CVEs.
How often should modules be reviewed?
The inventory against vulnerability databases makes sense continuously, or at least monthly, because a module that is clean today can have a public exploit tomorrow without you having touched anything. The in-depth review —custom module code and testing of the endpoints they expose— is repeated when the module set changes or after significant development, not every cycle.
Does a WAF replace patching the modules?
No. A WAF can stop generic exploitation of a known flaw and is a useful mitigation while the update is being prepared, but it relies on signatures and patterns: a variant of the exploit, a differently encoded request or a business logic flaw goes through without anything firing. It buys time; it does not close the loop.
What do you need to audit our custom modules?
The source code of those modules, a staging installation where the behaviour can be reproduced, test accounts for customers and employees with whatever profiles exist, and knowing which external integrations each module touches. The analysis combines code review with testing against the controllers and endpoints the module registers, because a flaw in the code only really matters if it is reachable.
What is delivered at the end?
The full inventory of modules with their version, maintenance status and associated known vulnerabilities; findings on the custom code with proof of concept; the recommended decision for each problematic module (update, replace, remove or isolate); and a remediation plan ordered by real risk, not by the theoretical CVE score.