CyberISolve

Incident Response

Case Study: Removing a ClickFix Malware Infection From a Compromised WordPress Site

July 14, 2026 · 9 min read

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 is a walkthrough of how that engagement actually went, including 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 writeup should hand out.

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 we found during clean-up

A full-site audit turned up more than the one obviously malicious script. In total, the clean-up involved:

  • Removing three malicious plugins — one impersonating a legitimate caching plugin, disguised specifically to avoid a casual plugin-list review
  • Locating and removing multiple backdoor files hidden inside theme directories and the uploads folder, disguised with names close to legitimate WordPress core files
  • Identifying and removing two rogue administrator accounts the attacker had created weeks earlier, both with generic names designed to blend into a busy user list
  • Removing the injected ClickFix overlay script itself, which had been added to a theme template file so it would survive a plugin-only clean-up
  • Auditing the database for injected redirect and cloaking rules that showed search engines different content than human visitors saw
  • Reviewing the file system for any remaining unauthorized files, including 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.

A proper clean-up has to account for everything an attacker could have planted during the entire window they had access, not just the file that happens to be causing the visible symptom today.

Closing the door for good

After the clean-up, hardening focused on the actual entry point and the persistence mechanisms we 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

What to do if you see this on your own site

If visitors report a strange verification prompt, or you notice unfamiliar admin accounts, unexpected redirects, or plugins you don’t remember installing, treat it as an active incident: take the site offline or behind maintenance mode if you can, don’t simply delete the obvious file and assume it’s resolved, and get a full audit rather than a surface clean-up. If your site is actively serving the ClickFix prompt to visitors right now, that’s urgent — it’s attacking the people who trust your site, not just your own systems.

If you’re dealing with this on your own WordPress site, 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.

← All Blogs

Related reading

Dealing with something similar?

Tell us what's going on — active incidents get a same-day response, 24/7.