Fake Cloudflare CAPTCHA on your WordPress site: how to find the “Verify you are human” script and remove it

A fake Cloudflare CAPTCHA on your WordPress site means someone has injected a script into your theme, a plugin or the database. The box asks visitors to paste a command into Windows, and that command installs malware on their computer. Find the script, stop it showing, clean the site and close the way the attacker got in.

Why are visitors seeing a fake Cloudflare CAPTCHA on my WordPress site?

Because your site has been hacked and is serving a ClickFix page. Real Cloudflare checks never ask anyone to open the Run box or paste a command. The fake one does, and it usually covers the whole page a second or two after it loads.

New Zealand’s National Cyber Security Centre lists the signs in its alert on compromised websites serving ClickFix pages (published 2 September 2026, read 20 October 2026). They include a fake Cloudflare “Verify You Are Human” page, full-screen overlays shortly after the page loads, and JavaScript that copies PowerShell or shell commands to the clipboard. The alert says ClickFix campaigns commonly use compromised WordPress websites.

It is not always dressed as Cloudflare. Sucuri found a variant posing as Google reCAPTCHA (Sucuri, WordPress ClickFix malware causes Google warnings, 21 February 2025, read 20 October 2026).

This guide covers the owner’s side: find the script, stop it showing, clean up and close the way in. Our plugin, Security Guard, helps with the first two steps only.

If you ran the command on your own computer, jump to what to do if you ran the command.

Why do visitors say their browser or uBlock Origin blocked my site?

Because blocklists catch these campaigns, often before the site owner notices anything. A warning page in front of your site is frequently the first report you get.

Sucuri’s February 2025 write-up describes Google showing a warning page in place of ClickFix-infected WordPress sites. uBlock Origin added a ClickFix section to its built-in badware filter list aimed at known attack infrastructure, which CyberInsider reported on 6 July 2026 (read 20 October 2026).

Why can’t I see the fake CAPTCHA when I’m logged in?

Because the injected code usually hides from you. A script running inside WordPress can check for the login cookie and skip anyone who is signed in. It can also skip visitors it has already shown the page to, or traffic that looks like a crawler.

The NCSC alert says attackers often hide the content from scanners and crawlers, and advises testing from private browsing, different IP addresses, and both mobile and desktop. In practice: open a private window on a phone using mobile data, visit the home page and a blog post, and wait ten seconds before you decide the site is clean.

What does the fake CAPTCHA do to a visitor who follows it?

It gets them to run malware themselves. The page copies a hidden command to the clipboard, then tells the visitor to press Win+R, paste and press Enter.

Microsoft Threat Intelligence describes the same three steps in Think before you Click(Fix) (21 August 2025, read 20 October 2026). In the case Sucuri documented on 21 May 2025 (read 20 October 2026), that command downloaded a malicious Windows program.

The damage lands on the visitor’s computer, not your server. That is how it runs for weeks unnoticed.

Where does the loader hide in WordPress?

In one of three places: theme files, plugin files or the database. Google’s threat intelligence team names exactly those three for the UNC5142 campaign, in New Group on the Block: UNC5142 (GTIG, 17 October 2025, read 20 October 2026).

• Theme files. GTIG names header.php, footer.php and index.php. Sucuri found code in the active theme’s functions.php in February 2025, and in May 2025 it found header.php infected in every installed theme, calling a second file, verification.html, that held the fake Cloudflare page.
• Plugins. A changed plugin file or a new plugin. GoDaddy’s security team reported fake plugins installed with stolen logins on over 6,000 sites (GoDaddy, 17 October 2024, read 20 October 2026).
• Must-use plugins. Files in wp-content/mu-plugins run on every request and stay off the normal Plugins list.
• The database. GTIG says code can go straight into the database: a post, a widget or an option.

Expect more than one copy, and a second way back in.

What is EtherHiding, and why is there no bad domain to block?

EtherHiding is a loader that stores its next stage in a smart contract on a public blockchain, so the script on your site fetches it from a blockchain node, not from a server the attacker owns. Guardio Labs named the technique in a write-up on 13 October 2023 (read 20 October 2026), describing Binance Smart Chain contracts used to host parts of the chain behind hijacked WordPress sites.

The fetch is a read-only eth_call. Guardio notes that it is cost-free and is not recorded on the blockchain. Google’s DPRK Adopts EtherHiding (GTIG, 17 October 2025, read 20 October 2026) adds that it creates no transaction and avoids gas fees.

So there is no attacker domain to block. The loader talks to a public RPC endpoint that honest apps also use, and the payload changes when the contract does. GTIG puts a typical UNC5142 update at $0.25 to $1.50 in network fees.

As of June 2025, GTIG had found about 14,000 web pages with injected JavaScript consistent with UNC5142, and it has not seen that group active since late July 2025. The technique is not tied to one group: Sucuri’s February 2025 case also pulled its code from the blockchain, on over 5,200 sites by its SiteCheck count.

Security Guard was written after this pattern hit a production WordPress site: the loader fetched its second stage from a public blockchain RPC endpoint, so there was no domain to block.

How do I find the injected script by hand?

Start from the page a visitor gets, then work back to the file or database row behind it. These steps use SSH and WP-CLI; a file manager and phpMyAdmin work too, only slower.

1. Save the page as a logged-out visitor sees it. curl -s -A "Mozilla/5.0" https://example.com/ > page.html, then search it for eth_call, clipboard, powershell and verify you are human.
2. Check core files. wp core verify-checksums compares WordPress core with the official checksums. wp plugin verify-checksums --all does the same for plugins from WordPress.org.
3. Search the code. grep -rlE "eth_call|clipboard\.writeText|powershell" wp-content/themes wp-content/plugins wp-content/mu-plugins. Then open header.php, footer.php and functions.php of every installed theme, not only the active one.
4. List recent changes. find wp-content -name "*.php" -mtime -30 shows PHP files changed in the last 30 days.
5. Look in must-use plugins. ls -la wp-content/mu-plugins. Every file there should be one you or your host can explain.
6. Search the database. wp db search "eth_call" and wp db search "clipboard" look through every WordPress table.
7. Count your administrators in SQL. The Users screen can be filtered by a backdoor. Our guide on how to check if a WordPress site is hacked has the query that reads the user tables directly.

The Security Guard scan covers steps 2 to 6 in one read-only run. Under Settings, Security Guard, the Run full scan button reads plugin, theme and must-use code, uploads, posts, post meta and options, and checks core files against WordPress.org. Its rules include “Clipboard write followed by a shell command (ClickFix)”, “Fake human-verification asking the visitor to paste a command”, “Blockchain JSON-RPC method call (EtherHiding pattern)” and “Public blockchain RPC endpoint referenced”. Each finding gives the file and line, or the post, option or user.

Know its limits before you rely on it. The rules are signatures, so a newly written loader may not match until we add it; comparing against a saved baseline catches changed files either way. It cannot see an administrator hidden by a pre_user_query filter, so do step 7 yourself. It reports and never deletes or edits what it flags.

How do I stop the fake CAPTCHA showing to visitors while I clean up?

Strip the script from pages as they are sent, then stop the browser calling hosts you have not approved. Cleaning takes hours or days, and every visit until then puts a visitor at risk. If you can do neither, take the site offline, as the NCSC advises.

This is the part we built Security Guard for ($49 a year for one site). On the Protection tab, Remove injected scripts is on by default. It checks the inline scripts in each page WordPress builds and removes the ones that match the ClickFix and blockchain rules, leaving a High line in the Event log for each removal. On 20 October 2026 we planted an EtherHiding-style loader and a ClickFix clipboard script on our lab site. With the filter on, both came out of the page and each left a High line in the log, while the theme’s own scripts stayed.

The filter checks inline scripts. A loader pulled in by a src attribute from another host is removed only when you also tick Strict script allow-list, which drops external scripts from hosts not listed in Allowed script hosts. Try it on a staging copy first.

Purge your page cache after switching it on. The filter works on pages as WordPress generates them, so a copy cached before then still holds the script.

The second layer is a Content-Security-Policy with a connect-src directive. MDN’s connect-src reference (last modified 3 July 2026, read 20 October 2026) explains that it restricts the URLs scripts can load through fetch(), XMLHttpRequest, WebSocket and similar interfaces. An eth_call from the browser is one of those requests, so a policy that does not list the RPC host makes the call fail.

1. On the Protection tab, set Content-Security-Policy mode to Report only (recommended first). The policy allows calls to your own site plus the hosts in Allowed connect hosts.
2. Use the site for a few days, checkout and forms included. Blocked hosts appear in the Event log and nothing breaks.
3. Add the hosts you recognise to Allowed connect hosts. Leave out anything you cannot explain.
4. Switch the mode to Enforce once the log stays quiet.

Neither layer is a cure. Malware that edits your theme’s PHP can also change headers or reshape its script so the rules miss it. Use them while you clean, not instead of cleaning.

How do I remove the infection for good?

Replace code rather than editing it, then clean the database and every login. Security Guard does none of this for you.

1. Back up the infected site first, files and database, so you can trace the way in later.
2. Replace WordPress core: wp core download --force --skip-content.
3. Reinstall every plugin from its source, for example wp plugin install akismet --force, and delete any plugin you did not install.
4. Restore every theme from a clean copy, and delete themes you do not use.
5. Remove unknown must-use plugins, any PHP file in wp-content/uploads and the injected database rows.
6. Delete administrators you cannot account for, using the SQL count.
7. Reset passwords for every administrator, hosting, SFTP and the database, then run wp config shuffle-salts to log everyone out.
8. Purge every cache and test again from a private window on mobile data.

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

Usually through an outdated plugin or theme, or a stolen login. GTIG reports UNC5142 going after WordPress sites running vulnerable versions of WordPress, plugins or themes. GoDaddy’s October 2024 report describes the other route: attackers logging in with stolen credentials and installing fake plugins, unrelated to any known WordPress vulnerability.

Check both. Update everything, remove unused plugins and themes, and read your access logs around the date of the first infected file for logins from unfamiliar addresses. Then follow the NCSC’s longer-term list: multi-factor authentication for every admin, least-privilege accounts, dashboard file editing switched off and file integrity monitoring.

Skip this and the overlay usually comes back.

What should I tell visitors who ran the command?

Tell them plainly that your site showed a fake check, that the command may have installed malware, and that they should treat their computer as compromised.

• Do not run any other command a website suggests.
• Run a full scan with up-to-date security software, and ask their IT team for help if it is a work computer.
• Change important passwords from a different, clean device, starting with email and banking, and sign out of other sessions.
• Read the NCSC’s ClickFix alert for its full advice to people who interacted with the prompt.

Sucuri puts the rule in one line: visitors should never run commands using Win+R just because a website tells them to.

Is Security Guard the right tool for this?

It fits two steps: finding the loader and keeping it from visitors while you clean. It is not a firewall, it removes no malware, and multisite is not tested yet. On Nginx you need your own rule to block PHP in uploads.

If you have no time to clean the site yourself, a professional cleanup service is the better first call. Read the Security Guard user guide for each screen, and our comparison of WordPress malware scanners for tools that include cleanup.

Not sure which step you are on? Tell us what visitors saw and what your scan found, and we will tell you where to start: ask about a hacked site.