1 The Challenge
A client came to us after a regular visitor flagged something odd: loading their site briefly showed a fake “verify you are human” prompt before the real page appeared, and it was instructing visitors to open the Windows Run dialog and paste in a command. That’s the signature of ClickFix, a malware delivery technique that’s become one of the most common ways compromised WordPress sites get weaponized against their own visitors, not just defaced.
This account covers what we found and what we changed so it wouldn’t come back, without republishing the specific payloads or commands involved, since that’s not something a public write-up should hand out.
2 Our Assessment
What ClickFix actually does
ClickFix isn’t a WordPress vulnerability by itself, it’s a social-engineering payload that gets injected into a site after it’s already been compromised through some other means. The injected script shows visitors a fake CAPTCHA, browser update prompt, or “verification” overlay, then instructs them to press a key combination that opens a command dialog and paste in text the page has already copied to their clipboard. Visitors who follow the prompt run that command themselves, which typically installs an information-stealer or remote-access trojan on their own machine.
The dangerous part is that it turns a compromised website into a distribution point that attacks your visitors, not just your site, which is exactly why it needs to be treated as an active incident, not a cosmetic clean-up.
How the site was compromised in the first place
The initial entry point traced back to an outdated, vulnerable contact-form plugin the client had installed years earlier and stopped updating. That single unpatched plugin gave an attacker file-upload access, which they used to establish persistence well before the ClickFix overlay ever appeared, the visible symptom was the last step of a much older compromise, not the first.
What a full audit turned up
A full-site audit found more than the one obviously malicious script. In total, the assessment surfaced:
- Three malicious plugins, one impersonating a legitimate caching plugin, disguised specifically to avoid a casual plugin-list review
- Multiple backdoor files hidden inside theme directories and the uploads folder, disguised with names close to legitimate WordPress core files
- Two rogue administrator accounts the attacker had created weeks earlier, both with generic names designed to blend into a busy user list
- The injected ClickFix overlay script itself, added to a theme template file so it would survive a plugin-only clean-up
- Injected redirect and cloaking rules in the database, showing search engines different content than human visitors saw
- A scheduled task the attacker had set up to re-inject the payload if the visible script was removed without addressing the source
Why “just delete the plugin” doesn’t work
This is the part most DIY clean-ups miss, and it’s the reason reinfections happen so fast: removing the visible malicious plugin or script deals with the symptom, not the access. If a backdoor file and a rogue admin account are still in place, the attacker doesn’t need the original vulnerability anymore, they already have a working way back in. We see sites get “cleaned” and reinfected within days specifically because of this.
3 The Solution
After the clean-up, hardening focused on the actual entry point and the persistence mechanisms the assessment found:
- Removed the outdated contact-form plugin entirely and replaced it with an actively maintained alternative
- Forced a password reset for every legitimate admin and editor account, and enabled MFA on all administrator accounts
- Enabled file integrity monitoring so any unauthorized file change triggers an alert instead of sitting undetected for weeks
- Deployed a WAF with rules tuned to catch the file-upload and code-injection patterns used in the original compromise
- Set up a plugin update and audit schedule so an abandoned plugin doesn’t sit unpatched for years again
- Verified backups by actually performing a test restore, the client’s existing backups had never been tested and turned out to be incomplete
4 The Result
The ClickFix overlay and every backdoor, rogue account, and scheduled re-infection task were removed the same week the client reported the issue. A subsequent test restore confirmed the client’s backups actually worked, the first time they’d ever been verified. The site has had no reinfection since, because the fix addressed every access path the audit found, not just the script visitors could see.
5 Business Impact
A WordPress site that’s actively serving malware to its own visitors carries risk well beyond the technical compromise: search engines can flag or delist a site distributing malware, and visitors affected by the payload can reasonably hold the site responsible for what it served them. Closing the case with confidence that the access itself was gone, not just the visible symptom, is what let the client put the incident behind them instead of waiting for a second, faster reinfection.
If you notice a strange verification prompt, unfamiliar admin accounts, unexpected redirects, or plugins you don’t remember installing, treat it as an active incident: don’t simply delete the obvious file and assume it’s resolved. Our WordPress Management & Security team handles this exact type of clean-up, and our incident response line is monitored around the clock for active compromises.