PrestaShop store hacked: the fake “verify you are human” is ClickFix

A customer emails you: when they opened your store, a “verify you are human” box asked them to press two keys, paste something and hit Enter. You check and see nothing wrong. If this has happened to you, your PrestaShop store has been hacked with ClickFix: someone has slipped in a piece of code that shows that fake captcha to your visitors so they install a malicious program themselves, usually one that steals passwords.

It won't go away on its own: someone got into your store and left it there. It can be cleaned up, but what really matters is closing the door they came in through. And you are not alone: on 3 September Netskope counted more than 5,400 infected websites in this campaign, almost all of them small businesses. The ones they examined one by one were mostly WordPress and sometimes PrestaShop.

What is ClickFix, and why can't you see it?

The page blurs behind a fake captcha that asks you to press the Windows key and R, paste and press Enter. What gets pasted is a command the page has already copied without telling anyone, and running it installs the attacker's program. A real captcha never asks you to open anything on your computer.

Not seeing it doesn't mean it isn't there. The code in your store fetches the trap from somewhere else every time a page opens, and the attacker decides what is shown and to whom without touching your store again. It targets Windows computers, and the variant The Hacker News described on 6 October even hides the program in the visitor's browser before asking them to do anything.

How do I know if my store has it?

• Ask the customer for a screenshot and the time it appeared: with that, your developer knows what to look for.
• Open the store from a Windows computer, in a private window, without logging in to the back office and from a different connection, such as your phone's hotspot.
• Check Search Console, under Security & Manual actions → Security issues. If Google has already detected it, Chrome may be warning your customers that your site is dangerous.

The customer's screenshot is enough to get started.

What to do today, in order

1. Make a full backup, files and database, and keep it off the server before you touch anything. Whoever cleans up will need it.
2. Put the store into maintenance mode, under Shop Parameters → General → Maintenance. That page loads neither the theme's JavaScript nor the header modules, so it almost always cuts off the fake captcha, and it tells Google you are only closed for a while. Check from another connection: your IP can still see the store.
3. Change every password: back-office employees, hosting, FTP and database. Under Advanced Parameters → Team, delete any employee you don't recognise, and under Advanced Parameters → Security, close every back-office session. Do it again once the store is clean.
4. Find the code and the back door with your developer: whoever gets in usually leaves files behind so they can come back. Where to look is below.
5. Close the door they came in through, or it will happen again tomorrow.
6. Clear the caches before reopening: PrestaShop's, under Advanced Parameters → Performance, and Cloudflare's if you use it. The store may be serving a combined copy of the theme's JavaScript that keeps the code even after the original is cleaned. If Google had flagged you, request a review.
7. If a customer pasted the command, tell them to run an antivirus scan and change the passwords saved in their browser. And if the intruder could see your customers' data, talk to whoever handles your data protection: the GDPR gives you 72 hours to report it.

Where does it hide in PrestaShop?

In the database, in a field the store prints on every page, or in the files: Netskope found it appended to legitimate JavaScript files and in folders that imitate a real plugin. The French merchant who described it on 5 October on the PrestaShop forum, with a 1.7.8 store, found nothing in his database, and the back doors were in files across several folders.

• Custom code fields. Many themes and analytics modules have a box for pasting code into the page header; in the Warehouse theme it is under Design → IqitThemeEditor, on the codes tab. Any code you can't account for goes, even if it looks like a known tool: one used in this campaign posed as Microsoft Clarity.
• Pages and product pages. CMS pages and product and category descriptions accept HTML, and a script fits in there.
• Modules. Under Modules → Module Manager, any module you didn't install yourself.
• Stray files. In a clean PrestaShop, the image, upload and download folders contain no PHP other than index.php. One more, or one whose name starts with a dot and that your FTP program hides, is a back door.

The check under Advanced Parameters → Information → List of changed files only looks at whether core files have changed: not the theme, not the modules, not the images, and not files that were added. An empty list doesn't mean a clean store.

How did they get in, and how do I close the door?

Netskope doesn't know yet how those sites were compromised. On PrestaShop, the usual doors are a module with a known flaw that was never updated, a stolen or easy back-office password, and “nulled” modules, paid modules downloaded for free from pirate sites, which often come with the back door already installed.

• Update your modules, starting with faceted search. On 3 June PrestaShop warned of a serious flaw in ps_facetedsearch, the catalogue filters module that ships with PrestaShop: anyone, without an account, could run code on your server. It is fixed in 4.0.4; if you had an older version, assume it may have been the way in. And remove modules you don't use.
• Protect the back office. A long, different password for each employee, no shared accounts and a back-office address that isn't /admin. A second step with a code on your phone doesn't come built in, but a module adds it.
• Put a firewall in front, such as Cloudflare: it stops many automated attacks before they reach the store, as we explained in how to rate-limit requests per IP without blocking Google. PrestaShop itself points out it is an extra layer, not a substitute for updating.
• Move off 1.7. PrestaShop stopped maintaining it when it released 9.0, in June 2025. It was the version the forum store was running.

For your technical team

Read-only queries; replace ps_ with the store's prefix. Warehouse stores its code fields escaped, so search for <script as well.

SELECT name, LEFT(value, 120)
  FROM ps_configuration
 WHERE value LIKE '%<script%'
    OR value LIKE '%&lt;script%'
    OR value LIKE '%eth_call%'
    OR name LIKE '%codes_js';
SELECT id_cms, id_lang
  FROM ps_cms_lang
 WHERE content LIKE '%<script%';
SELECT id_employee, email,
       id_profile, active,
       last_connection_date
  FROM ps_employee
 ORDER BY id_employee DESC;

In the files, from the store's root:

find img upload download \
  -name '*.php' ! -name index.php
find . -name '.*.php'
find . -type f -mtime -30 \
  \( -name '*.php' -o -name '*.js' \) \
  -not -path './var/cache/*'
grep -rl -e eth_call -e prebsc \
  -e bsc-testnet -e claritydelivr \
  --include=*.js --include=*.php \
  --include=*.tpl .

The campaign's indicators are in Netskope's list. Reinstalling the core and modules from clean packages of the same version is safer than deleting file by file; afterwards, clear var/cache and themes/*/assets/cache. PrestaShop 9 ships an .htaccess that blocks PHP from running in img, upload, download, js, vendor and modules: make sure they are still there and, on Nginx, which doesn't read them, carry those rules into the server configuration.

When should you ask for help?

If you've found something and have nobody to clean it up, if it came back after cleaning, or if you don't know where to start. It's part of our support and maintenance service: we clean the store, find out how they got in and close the door. Send us your customer's screenshot and your PrestaShop version, and we'll look at it the same day or the next.

Tell us what your customer saw