If you've spent any time on the security side of the internet this week, you've probably seen the headlines: thousands of otherwise legitimate websites have been quietly hijacked to serve fake "verification" prompts that trick visitors into infecting their own machines. Malwarebytes' reporting, picked up widely this week, walks through how the campaign works. It's a good story. It's also, quietly, a story about a missing HTTP header.
How the Attack Actually Works
The technique has a name now "ClickFix" and it's uncomfortably clever. A visitor lands on a normal-looking site: a small business, a blog, a storefront running PrestaShop. Buried in that page is malicious JavaScript, either slipped into a legitimate script file or tucked away in a fake plugin directory. That script's only job is to render a convincing fake CAPTCHA or "security verification" overlay.
Except this CAPTCHA doesn't ask you to click traffic lights. It asks you to open the Windows Run dialog, paste something, and hit enter. Because the instructions look like routine browser security theatre on a site the visitor already trusts, a meaningful number of people just do it. What they've pasted is a command that pulls down malware and executes it, no download prompt, no antivirus popup at the border, because the user drove straight through the checkpoint themselves.
Researchers haven't pinned down exactly how attackers first got into these sites, but the part that matters for site owners isn't the initial foothold. It's what happened after: a script from nowhere in particular got to run, unrestricted, on someone else's origin.
The Gap Nobody in the Coverage Is Naming
We read through the coverage on this campaign, and it's almost entirely aimed at the end user: don't paste things into Run dialogs, keep your antivirus updated, be suspicious of CAPTCHAs. All fair advice. None of it is advice the site owner can act on.
Here's the thing a strict Content Security Policy is specifically built to stop: a script executing on your page that you didn't put there and didn't authorise. If a site had shipped a script-src directive scoped to its own domain and a short, known allowlist of third-party hosts — no unsafe-inline, no wildcard, that injected payload would have had nowhere to run. The browser would have blocked it outright and, if the site had report-uri or report-to configured, would have told the site owner about the attempted injection before a single visitor ever saw a fake CAPTCHA.
That's the frustrating part of stories like this one. The defence isn't exotic. It's a header that's been a W3C standard for over a decade. Most sites either don't have one, have one so loose it doesn't do anything, or had a good policy once that quietly rotted as plugins and scripts got added over the years without anyone updating it.
Where This Actually Gets Fixed
This is exactly the gap HeaderCentaur is built to close, and it's worth being precise about what that means: we don't write your policy for you (Yet!). You still decide what belongs in script-src. What HeaderCentaur does is make sure you're never guessing about the state of your headers, and never the last to know when something's wrong.
Start with the header scanner. Run it against a site like the ones in this campaign and it will flag exactly the kind of weakness that made the attack possible in the first place: no CSP at all, or a script-src so loose (unsafe-inline, a bare *, a forgotten wildcard subdomain) that it wouldn't have stopped anything anyway. That's the audit most WordPress and PrestaShop sites have simply never run, plugins get installed, scripts get added, and nobody circles back to check whether the site's headers still mean anything.
The second half is what happens after you do have a policy in place. Point your CSP's report-uri or report-to at HeaderCentaur and every violation. Every script your browser blocked because it didn't match your policy lands in a dashboard instead of nowhere. In a campaign like this one, that's the difference between finding out a script got injected because a violation report showed up within minutes, and finding out because a customer called, or because your site turned up in a headline like the ones this week.
The Takeaway
Nobody in this campaign's aftermath is going to blame a missing CSP header, because it's invisible right up until it's the only thing standing between an attacker's script and your visitors' machines. If you haven't checked what your site's headers would actually catch today, that's the five-minute scan worth running before this campaign or the next one reaches your domain instead of someone else's.
Run a free header scan with HeaderCentaur, or register to wire up your CSP reporting and start seeing violations the moment they happen.
Sources: CyberGuy: Thousands of hacked sites trick you into installing malware