ClickFix Protection

Stop your website telling visitors to run malware

ClickFix lures are injected into legitimate sites and talk visitors into pasting a malicious command themselves. Report URI uses reports from your visitors' browsers to spot the injected script, the connections it makes and the fake overlay, even if you never see them yourself. Then you can block them.

Start 30-Day Free Trial See how it works

Trusted by Security Teams

How ClickFix Works

The visitor is tricked into running the malware themselves

There's no browser exploit involved. A fake verification step or error message appears on a site the visitor trusts, a script copies a command to their clipboard, and the instructions on screen walk them through running it. The browser never downloads anything malicious, so download protection has nothing to catch.

Inject

Inject

A loader is added to a legitimate site through a vulnerable plugin, a stolen admin login or a compromised tag. It is usually disguised as analytics, a font service or a CDN. Your server serves the page as normal.

Lure

Lure

The loader fetches its instructions, often over a WebSocket or from a blockchain smart contract, and renders a fake CAPTCHA or Cloudflare check. It is shown only to the visitors it targets, so your own testing never triggers it.

Execute

Execute

The visitor pastes the command into the Run dialog or a terminal and presses Enter. It downloads and runs an infostealer, which takes their saved passwords, browser sessions and crypto wallets. They were on your website when it happened.

We track ClickFix infrastructure as part of our threat research. Read how a WebSocket-driven chain works, and how one campaign reached thousands of WordPress sites →

What Report URI Does

Every stage before the paste happens on your page

You can't protect your visitors' computers. You can see what your page does in their browsers, and decide what it is allowed to do. No agents, no injected scripts, no code running on your behalf.

Script Watch

Catch the injected loader

Script Watch keeps an inventory of every script your pages load, built from real visitors' browsers. A ClickFix loader is a script that wasn't there yesterday, so it shows up as new, with when it first appeared and which pages it was seen on.

Learn more about Script Watch →
Data Watch

Catch it calling home

The loader has to fetch its overlay and its command from somewhere. A brochure page has no reason to open a WebSocket to a week-old domain, or to read a blockchain RPC endpoint. Data Watch tracks every destination your pages connect to and alerts you when a new one appears.

Learn more about Data Watch →
Frame Watch

Catch the overlay

Some kits render the fake "security check" as a full-screen iframe from another origin. Frame Watch keeps an inventory of every frame your site embeds and tells you the first time a new one is seen.

Learn more about Frame Watch →
Threat Intelligence

Know which alert to act on first

Script Watch tells you a script is new. Threat Intelligence tells you if it's already known to be malicious. We check every host in your reports against the infrastructure we track, and flag known ClickFix hosts on the report itself.

Learn more about Threat Intelligence → Read our threat research →
CSP Enforcement + Connection Allowlist

Stop it from running

Once you know what your site legitimately loads, enforce it. An enforced Content Security Policy refuses a loader from a host you never allowed, so the overlay never renders and nothing is written to the clipboard.

A Connection Allowlist blocks the call home. Name the destinations your pages may reach and the browser refuses the rest, including the WebSocket or blockchain RPC request a loader needs to fetch its overlay and command.

Learn more about CSP Reporting → Learn more about Connection Allowlist →
Why It Gets Missed

Why site owners don't notice their site is serving ClickFix

The lure renders in the visitor's browser, for the visitors it chooses. Most of the tools a site owner relies on never look there.

Your Own Testing

It hides from you

Kits filter by operating system, first visit and logged-in status. You can browse your own site all day and never see the overlay your visitors are getting.

Server Logs

There's nothing to log

The overlay, the clipboard write and the call home all happen in the browser. Your server logs show a normal page view.

CMS Updates

Patching doesn't remove it

On WordPress, the loader is often added through the site's own script API from code left behind after the compromise. A core update leaves that code exactly where it was. See how that campaign worked →

Blocklists

The domains change daily

Operators rotate their domains constantly, sometimes registering a new one the morning it goes live. A list of known names is always a step behind.

Getting Started

Start reporting in minutes, across your whole site

A ClickFix lure can be injected into any page, so deploy a report-only policy across your whole site. It changes nothing about how your site behaves; it just tells you what loads.

HTTP response header
Content-Security-Policy-Report-Only: script-src 'self';
  connect-src 'self'; frame-src 'self';
  report-uri https://your-subdomain.report-uri.com/r/d/csp/reportOnly

Add the third parties you actually use. Anything that still shows up in your reports after that is worth a look. Once the policy has settled, move it to enforcement.

No agent to install

Sees what loaded for each visitor

Report-only first, nothing breaks

Site functions normally even if Report URI is unavailable

Scope

ClickFix protection: what's covered

Report URI covers the part of a ClickFix attack that happens on your pages. The last step, running the pasted command, happens on the visitor's own computer, which no website can reach.

Report URI covers Doesn't replace
Detecting injected scripts on your pages Endpoint protection on your visitors' devices
Detecting new connections and frames Malware cleanup on a compromised site
Blocking unauthorised scripts and destinations Incident response for visitors who ran the command
Matching hosts against known ClickFix infrastructure Patching the vulnerability that let the attacker in

Nothing of ours runs on your pages, so there is no new script for an attacker to compromise.

Get Started

See what's loading for your visitors

It's one header, there's nothing to install, and nothing gets blocked until you decide to enforce.

Start 30-Day Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No infrastructure changes

FAQ

Frequently asked questions

A page shows what looks like a CAPTCHA, a Cloudflare check or an error message, and tells the visitor to fix it by pasting a command into the Run dialog or a terminal. A script has already put that command on their clipboard. The command downloads and runs malware, usually an infostealer. The browser never downloads anything malicious itself, so browser download protection has nothing to act on.

Because it has been compromised. Much ClickFix traffic comes from ordinary sites with a script injected into their pages, through a vulnerable plugin, a stolen admin login or a compromised third-party tag. The site owner is a victim too, but the lure is served under their name, to their visitors.

Most kits only show the overlay to some visitors: Windows only or macOS only, first visit only, never to a logged-in admin, never to a known crawler. The injected script is still on the page, and it still has to load and connect somewhere, which your visitors' browsers can report even when you never see the overlay yourself.

The injected loader has to come from somewhere, which is a script-src load. It has to fetch its instructions, which is a connect-src connection, and connect-src covers WebSockets. Some kits render the overlay as a full-screen iframe, which is a frame-src load. A policy reports all three, and in Report-Only mode it does so without blocking anything.

You don't need to. Script Watch and Data Watch alert on any host that is new to your site, whatever it is called, and Threat Intelligence flags the ones already tied to a campaign.

No. The data comes from a browser feature you turn on with a response header, so nothing of ours executes on your pages. A report-only policy changes nothing about how your site behaves.

Remove the compromise at its source, not just the script tag. On WordPress that means looking beyond core: must-use plugins, theme files and the options table are the usual hiding places, and a core update does not touch them. Rotate admin credentials, then keep the policy in place so you know if it comes back.