Hacked PrestaShop: detecting and removing a card skimmer

The worst hack is the one that breaks nothing

When a hacked PrestaShop store throws a 500 error, the merchant notices within the hour. When it is carrying a skimmer, everything carries on working perfectly: orders go through, customers pay, and a script injected into the payment page quietly copies card numbers to a third-party server.

The wave seen on PrestaShop in early 2026 follows this pattern. The way in is almost never the core: it is an out-of-date third-party module, sometimes installed years earlier and long forgotten.

Two consequences land immediately: your payment provider will treat you as no longer PCI DSS compliant, and you have 72 hours to notify your data protection authority under Article 33 of the GDPR.

The signals that should put you on alert

None of these is proof on its own, but each one deserves a look:

• customers report fraudulent charges shortly after ordering from you;
• your payment provider gets in touch about an unusual fraud rate;
• a JavaScript file in your theme has a recent modification date although you have published nothing;
• a <script> tag pointing at an unfamiliar domain appears in the source of the checkout page;
• Google Search Console flags deceptive content or indexed spam pages.

Exfiltration domains deliberately imitate legitimate services: names containing cdn, analytics, jquery, tag-manager, on unusual extensions. A domain that looks like Google without being google.com is the most reliable signal of the lot.

Diagnosis over SSH, in five commands

Files modified in the last seven days:

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Obfuscated code in themes and modules:

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Classic backdoors:

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

On the database side, a well-documented injection consists of slipping JavaScript into the shop name, which is then echoed back on every page:

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

An employee account you do not recognise, or a configuration value containing HTML, counts as confirmation.

The clean-up procedure

Cleaning a hacked site in the wrong order guarantees reinfection. The sequence matters.

1. Freeze the scene. Take a full copy of the files and the database before you touch anything. It is your only evidence and your only way of working out how they got in.

2. Stop the bleeding. Put the store into maintenance mode. As long as the payment page is live, card numbers keep leaving.

3. Restore the code from a clean source. Download the PrestaShop core again at the exact version installed and overwrite the files, preserving img/, upload/, download/, your in-house modules and config/settings.inc.php. Reinstall every third-party module from its vendor, never from an archive found on the server.

4. Clean the database. Repair the altered ps_configuration values, delete unknown employee accounts, and inspect CMS blocks and product descriptions for <script>.

5. Rotate everything. Employee passwords, the database password, FTP/SSH credentials, payment module API keys, and the cryptographic keys in config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Regenerating those keys logs out every session, the attacker's included.

6. Close the way in. Skip this step and reinfection follows within days. Update every module, check the advisories published by Friends-of-Presta for each of them, and apply the core security patches.

Hardening the store for the future

• Rename the admin directory and put an extra layer of HTTP authentication in front of it.
• Block PHP execution in img/, upload/ and download/ through the server configuration.
• Enable two-factor authentication on every employee account.
• Put a web application firewall and file integrity monitoring in place: a PHP file created in modules/ should raise an alert.
• Back up daily, with at least 30 days of retention. Seven days of backups are worth nothing against an intrusion discovered three weeks in.

If your store was compromised through an unpatched faceted search module, read our analysis of the ps_facetedsearch vulnerability as well.

Emergency response

A skimmer costs you more for every day it stays in place. We audit, clean and secure, with a written report on how they got in. Free diagnosis, reply within 1 hour — get in touch.