# My visitors see a fake "prove you're human" page

> Your customers describe a verification screen asking them to paste a command into their own computer, while you see nothing unusual from your browser: the infection picks its victims, and you are not one of them.

- Source canonique : [https://allaux.fr/en/securite/fausse-verification-humaine-sur-mon-site](https://allaux.fr/en/securite/fausse-verification-humaine-sur-mon-site)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Look for the code in the header.php file of every theme present on the server, not just the active one, and spot any stray .html file dropped into a theme folder. Sort by modification date over FTP: the touched files stand out. Then warn the customers who reported the screen, because the instructions they were given run on their own machine.

## You see nothing, and they are still right

A customer writes that before reaching your shop, they were shown a verification page announcing unusual traffic, with a message along the lines of "Unusual Web Traffic Detected", asking them to carry out an operation on their own computer to prove they are not a robot. You open your site: nothing. You reload: nothing. You try two other pages: still nothing. It is tempting to decide the customer landed on the wrong site, or has a dubious browser extension.

That is almost always wrong. The code is on your server. What changes is that it does not fire for everyone. Code injected into a theme can decide, on every page load, whether to serve the normal page or the trap, based on what it learns about the visitor: their browser, their operating system, where the visit came from, whether they are logged into the administration. I cannot tell you which criteria a given variant uses — it differs from campaign to campaign — but the principle holds: the site owner, who always arrives the same way, with the same session and the same browser, is the least likely visitor to see anything.

That is also what makes these infections last. As long as nobody reproduces the conditions of a real visitor, the site looks clean from the back office and the problem stays buried in customer service messages.

## What your customers describe

- An anti-robot verification screen appears before your page, although you never set one up.
- The message mentions unusual web traffic and shows English text you do not recognise.
- The visitor is asked to carry out an operation on their own computer to "prove they are human".
- It is intermittent: on the same link, one customer sees it and another does not.
- Some visitors are redirected to an outside page offering a browser update.
- From your usual browser, you see absolutely nothing.

## Where the code hides, and why every theme matters

In May 2025 Sucuri documented a campaign matching exactly what your customers describe. The malicious code is injected into the header.php file of every installed theme, not just the active one. It points to a verification.html file dropped on the server, which holds the fake verification page. The visitor reads that unusual traffic has been detected and that they must run an operation on their machine. If they follow it, they install malware on their own computer. It is an evolution of a campaign Sucuri had already seen in March 2025.

The key point is this: in this pattern the final victim is not your server. Your site is not stolen, not encrypted, its data does not necessarily leave. It acts as a distribution point. That explains the gap between what you measure — a site responding normally, orders coming through — and what your customers experience.

"Every installed theme" is not a detail for the curious. A theme you do not use, left behind after a trial or shipped by default, is still a PHP file on the server. Cleaning only the active theme leaves the rest in place, ready to be called again if the theme changes, and above all creates the belief that the job is done. So I always start from the assumption that the whole themes directory has to be inspected.

A second hiding place needs checking too. The wp-content/mu-plugins/ directory holds "must-use" plugins: they load automatically on every page render, without activation, and do not appear in the plugins list in the dashboard. A site audited only from the admin interface has a complete blind spot there.

## Reproduce, search, close it

1. **Stop being a known visitor** — Log out of the back office, open a private window, change browser, change device, use a mobile connection rather than the office network, and reach the site through an external link rather than typing the address. Every parameter you change brings you closer to a real visitor. Also ask your customer which browser and operating system they were using: that is the most useful thing they can give you.
2. **Compare the header files of every theme** — Open the header.php file of each theme present on the server, not only the active one, and compare it with a clean copy of the same theme version. A file modified recently, when you changed nothing, is enough to point the search.
3. **Look for files that have no business being there** — A verification.html file, or any stray HTML file in a theme folder or at the root, deserves to be opened and dated. Themes have no normal reason to host standalone HTML pages.
4. **Open the auto-loading plugins directory** — List the contents of wp-content/mu-plugins/ over file access, not from the dashboard. Sucuri observed three files there: redirect.php, sending visitors to an outside page posing as a browser update; index.php, a webshell granting remote access to the server; and custom-js-loader.php, which replaces site content with unwanted links and manipulates images.
5. **Date the changes before cleaning** — Record the modification dates of the affected files before restoring them. That is what lets you search the server logs for what happened that day and how access was obtained. Cleaning first and investigating afterwards destroys half the evidence.
6. **Close the door, not just the window** — Restore theme files from a clean source, delete the added files, then deal with the cause: update everything, review administrator accounts and remove those no longer needed, enforce unique passwords, enable two-factor authentication, and put file integrity monitoring and a web application firewall in place.

## Here it is your customers who are infected, not your site

> That is what makes this case unusual, and it changes what you owe people. A visitor who followed the instructions ran something on their own machine: no clean-up, no backup restore and no firewall of yours will disinfect it. Once the site is clean, a second job remains, and it cannot be done quietly: telling people. A short notice on the site and an email to the customers who reported the screen beat a polished statement published three weeks later. Say the page did not come from you, that it has been removed, and that anyone who followed the instructions should have their computer scanned and change their passwords from a different device. I clean servers; I do not disinfect your customers' machines, and nobody can do it remotely on their behalf.

## recherche-fichiers-modifies.sh

```
# Fichiers d'en-tete de theme modifies dans les 30 derniers jours
find wp-content/themes -name 'header.php' -mtime -30 -ls

# Fichiers HTML isoles deposes dans les dossiers de theme
find wp-content/themes -maxdepth 3 -name '*.html' -ls

# Contenu du dossier des extensions a chargement automatique
ls -la wp-content/mu-plugins/
```

## Related reading

- **My site redirects to an unknown site** — The variant where the visitor gets no intermediate screen at all and simply lands elsewhere. ([/securite/site-redirige-vers-site-inconnu](/securite/site-redirige-vers-site-inconnu))
- **My antivirus or browser blocks my site** — What happens next if the injection stays in place long enough to be detected. ([/securite/antivirus-navigateur-bloque-mon-site](/securite/antivirus-navigateur-bloque-mon-site))
- **Checking whether my site is compromised** — The checks to run when nothing is visible from your own browser. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Cleaning an infected site** — The order of operations once the modified files have been identified. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))

## FAQ

### Are my customers on the wrong site?

Possible, but very rare, especially when several people describe the same thing. An infection that does not fire for everyone produces exactly this picture: credible, matching reports, and an owner who can reproduce nothing from their own machine.

### Is the problem the visitor's computer?

Not at the start. The trap page is served by your site: the code is injected into theme files and points to a verification page dropped on the server. The visitor's machine is what gets infected if they follow the displayed instructions. The server is only the distribution point.

### Why inspect themes I do not even use?

Because the injection documented by Sucuri hits the header.php file of every installed theme, not just the active one. An unused theme is still code on the server, and cleaning only the active theme gives the illusion of a clean site.

### What do I tell a customer who followed the instructions?

To have their computer scanned with an up-to-date security tool, and to change the passwords of accounts used on that machine from a different device, starting with email and banking. I do not take on the disinfection of a customer's computer: that is an IT provider's job, not mine.

### Should I warn all my customers or only those who reported it?

The ones who reported it are, by definition, the ones who were not caught. It is the others who matter. A factual notice kept on the site for a few weeks, without drama, reaches visitors you have no other way of identifying.

### Once the site is cleaned, is it behind me?

Not until the way in is identified. The modified file is the consequence, not the cause. Without a full update, an administrator account review, unique passwords, two-factor authentication and file integrity monitoring, the same injection often returns to the same place.