ClickFix: the fake Cloudflare check that gets visitors to infect themselves

Most WordPress malware wants something from the site: a spam link, a redirect, a backdoor for later. ClickFix is different. It wants something from your visitors, and it gets it by asking politely.

What the visitor sees

A page that looks like a Cloudflare security check. Same layout, same wording, same reassuring tone. It says the verification needs one extra step, and gives instructions:

  1. Press a key combination to open a terminal or Run dialog.
  2. Paste the command already copied to your clipboard.
  3. Press Enter.

The clipboard was filled by the page itself. The command downloads and runs a payload. Nothing was exploited in the browser — the visitor was talked into running it.

Why it is effective

It defeats the defences people actually have. There is no drive-by exploit for a browser to block and no file download for an antivirus scanner to inspect — just text in a clipboard and a person following instructions. The interstitial is one people have been trained to see and wait through, and the instructions arrive with the authority of a security check.

What it looks like on the server

On a compromised WordPress site, the loader is usually injected so that it runs before anything else and appears on every page. Common shapes:

  • A drop-in. A file such as wp-content/db.php that WordPress loads automatically, very early, that no caching plugin installed.
  • A must-use plugin. Something in wp-content/mu-plugins, often padded with thousands of blank lines so the payload sits off-screen in an editor.
  • A hook into output. Code attached to wp_head, wp_footer or wp_body_open from outside your theme and plugins.
  • A hidden loader in core. A file with a leading dot and a random name, such as .g_7f4666da.php, dropped into a directory that is otherwise all real WordPress files.

The injection is often conditional: it skips logged-in users, skips repeat visitors, and sometimes skips anything that looks like a crawler. That is why an owner can browse their own site all day and see nothing wrong while visitors are served the fake check.

How to find it

  1. Look at the site the way a stranger does. A private window, not logged in, ideally from a different network. Many owners never see the payload because it is deliberately hidden from them.
  2. Compare core against core. Every file in the WordPress directories should match the official release for your version. Anything that does not is worth reading.
  3. Check the drop-ins. db.php, advanced-cache.php and object-cache.php are legitimate files that caching plugins install. If you have one and no plugin claims it, that is your candidate.
  4. Read the must-use directory. It is usually empty or nearly so. Anything enormous there deserves suspicion.
  5. List what prints into the head and footer. Output coming from outside your theme and plugins is the whole game.

Removing it properly

Deleting the loader is the easy half. The site was accessed somehow, and unless that route is closed the file comes back — often within a day.

  1. Quarantine rather than delete so a false positive is recoverable and you keep a copy of what was there.
  2. Audit the administrators. Remove accounts you did not create, and revoke every application password.
  3. Rotate every credential — WordPress, hosting panel, SFTP, database — and change the salts in wp-config.php to log every session out.
  4. Close the route in. In practice it is usually an outdated or abandoned plugin, or a file-manager plugin that was left installed.
  5. Block PHP execution in uploads and turn off the theme and plugin file editors, so the next foothold is harder to establish.
  6. Scan again the next day. Reinfection is the signal that the entry point is still open.

Tell your visitors

This is the part people skip. If the fake check was live, some visitors ran the command. They deserve to know, in plain language, that their machine may be compromised and that changing passwords from that machine is not enough. That notice is uncomfortable to write and much better than the alternative.

Finding it without doing all of that by hand

ClickFix Remover was built for exactly this injection. It searches every table in the database whatever your prefix is — page-builder data and widget content included, which is where these survive a file-only cleanup — as well as every PHP and JavaScript file. Its signatures match the actual shape of the loader: the obfuscated atob() block, the indirect (0,eval) call and the base64 payload. Turn its shield on and the injection is filtered out of page output immediately, so visitors are safe while you clean up properly. Everything it removes is backed up first.

Inovista Shield was written after cleaning five compromised sites on one hosting account, and the ClickFix loader was one of the things found there. It checks core files against the real release, flags unclaimed drop-ins and padded must-use plugins, reports anything printing into the head or footer from outside your code, and quarantines what you choose with a copy you can restore.