Hacked PrestaShop or OpenCart Store

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Running a store on PrestaShop or OpenCart means you get all the attention of an e-commerce target with a fraction of the security literature written for you. The attacks are the same ones hitting Magento and WooCommerce — card skimmers, spam injection, backdoors — and the cleanup principles transfer cleanly once you know where each platform keeps things.

Why stores are targeted

Two reasons, both about value. Card details flow through your checkout, and anything that can read a form field before submission is worth deploying. And stores hold customer records — names, addresses, order histories, sometimes accounts with reused passwords — which have their own market.

There is also an unglamorous third reason: smaller platforms often run on shared hosting with older PHP, fewer updates and more abandoned modules, because the shops using them tend to be small businesses without a developer on call. That is not a criticism of the software; it is a description of the population, and attackers scan for exactly that.

Where to look in PrestaShop

The modules directory is the usual entry point and a common hiding place, since third-party modules vary widely in quality and abandoned ones are everywhere. The override directory deserves particular attention, because it exists specifically to let code replace core behaviour — which is exactly what a backdoor wants to do, and it looks entirely legitimate sitting there.

Check the img and upload directories for executable files, check your active theme's templates, and check the database, where PrestaShop stores configuration values that get rendered into pages. Employee accounts in the back office should be audited for additions, and the configuration table for injected scripts.

Where to look in OpenCart

OpenCart's structure splits into catalogue and admin sides, each with their own controllers, models and views, so injected code can be sitting in either. The image directory is writable and should hold no PHP. The system directory holds the framework and the configuration files with your database credentials.

Extensions are the common vector here too, and OpenCart's modification system — which patches core behaviour at runtime from stored instructions — is worth checking carefully, since a malicious modification alters what the site does without changing the files you would think to inspect. Check the admin user list and, importantly, whether the admin directory has been renamed as recommended, since a default admin path invites brute-force attempts.

Checking for a skimmer specifically

If you take card details on your own pages, check for a skimmer before anything else. Load your checkout as a customer with developer tools open, account for every script, and watch the network panel while typing test data. A request going somewhere unfamiliar as you type is conclusive and urgent.

If you find one, treat it as a payment incident rather than a malware problem: take checkout offline, preserve evidence, notify your processor, and read my guides on card skimmers and PCI compliance. The obligations do not depend on which platform you run.

Cleaning up

The sequence is platform-independent. Preserve evidence, then replace core with a clean copy of your exact version, reinstall or remove third-party modules from original sources, delete executable files from media directories, sweep the database for injected content, remove accounts you did not create, and rotate every credential — database, admin, FTP, hosting and any API keys for payment or shipping integrations.

Then find the entry point in your logs, as covered in reading access logs, and close it. A store cleaned without closing the way in is a store that will be skimmed again, and the second incident is considerably more expensive than the first.

Securing the store

Update the platform and every module, and remove modules you do not use — on these platforms, unused abandoned modules are the single largest source of risk. Rename the admin directory if your platform expects it, put two-factor authentication on admin accounts where supported, and block PHP execution in image and upload directories.

Keep real backups, stored off the server, and test that you can restore one. My guide on backup and recovery covers doing that properly. And if you would rather have a store cleaned and verified by someone who does this daily rather than working it out under pressure while orders are stopped, that is what my malware removal service is for.

Related reading: hosted stores on Shopify. See also every platform I clean.

Common questions

Are these platforms less secure than WooCommerce or Magento?

Not fundamentally. The core software is maintained and patched. What differs is the ecosystem — more abandoned third-party modules, more sites running old versions without a developer maintaining them, and less security documentation aimed at owners. The risk comes from the population more than the code.

Where do I check first in PrestaShop?

The modules directory and the override directory. Overrides exist specifically to replace core behaviour, which makes malicious code there both effective and unremarkable-looking. Then media directories for executable files, your theme templates, and the configuration table in the database.

How do I check for a card skimmer?

Open your checkout as a customer would, with browser developer tools open. Account for every script the page loads, then watch the network panel while entering test card data. A request to an unfamiliar domain while you type is definitive, and it makes this an urgent payment incident.

Does renaming the admin directory actually help?

It does not stop a determined attacker who can find it another way, but it eliminates a large volume of automated brute-force traffic aimed at default paths, and it is free. Treat it as reducing noise and opportunistic attempts rather than as a security boundary.

What should I rotate after a compromise?

Everything the attacker could have read: database credentials, all admin passwords, FTP and hosting logins, and any API keys for payment, shipping or marketing integrations stored in the store's configuration. Those integration keys are the ones most often forgotten and can allow continued access after everything else is changed.