They Published 24 npm Packages That Nobody Was Ever Meant to Install. The Package Was Never the Weapon — the Registry Was the Free Hosting, and the Fake CAPTCHA Runs Cloudflare's Real One.
- Patrick Duggan
- 4 minutes ago
- 5 min read
Every npm supply-chain story you have read works the same way. The package is the weapon. It runs a post-install script, steals a token, backdoors a dependency, worms onward to the next maintainer. The victim is a developer, and the defence is install hygiene — pin your versions, audit your dependencies, run with --ignore-scripts.
OX Security has documented a cluster of 24 npm packages that inverts all of that.
Nobody is meant to install them. No developer is involved at any point. The packages exist so that npm and its mirrors will host an HTML file and serve it, fully rendered, on a domain your organisation trusts.
The package is not the payload. The registry is the hosting.
How the registry becomes a CDN for phishing
The mechanism is almost boring, which is what makes it good.
Anyone may publish to npm. It is free, instant, requires no domain registration, no hosting bill, no certificate, no reputation. Once published, the package is automatically mirrored — to unpkg, Yarn, npmmirror, Tencent's mirrors and others — within minutes.
Those mirrors do something the registry itself is more conservative about: they expose individual files directly, rather than only the compressed archive. That is a genuinely useful feature. It is why you can pull a single script off unpkg in a <script> tag instead of installing a whole dependency tree.
It also means that a link to a `.html` file inside a package returns a complete, live, rendered web page — served from the mirror's own domain, over the mirror's own valid TLS certificate, with the mirror's own reputation behind it.
One publish. Several trusted front doors. And the attacker never registered a domain for a blocklist to learn.
The detail that makes it work on careful people
The hosted page impersonates a Cloudflare security verification screen — the ClickFix pattern, where a fake "prove you're human" step is used to get the visitor to do something.
And it embeds Cloudflare's genuine Turnstile CAPTCHA.
Not a picture of one. Not a convincing copy. The real widget, loading from Cloudflare's real infrastructure, functioning correctly. You interact with it and it behaves exactly as the ones you pass twenty times a week behave.
Then the page runs heavily obfuscated JavaScript and redirects you to attacker-controlled phishing infrastructure — regardless of whether the verification succeeded. Passing was never a gate. The CAPTCHA is set dressing, borrowed from the legitimate vendor, on a page hosted by a legitimate registry, delivered over a legitimate certificate.
Think about what that does to a cautious user. The advice we have all given for a decade is check the URL, look for the padlock, be suspicious of pages that don't behave right. This page passes every one of those checks. The domain is real and reputable. The TLS is valid. The security widget is not merely convincing — it is the actual product from the actual vendor, working.
What this breaks, including for us
Domain reputation, threat feeds, blocklists and "hover before you click" all rest on one assumption: the attacker has to control a domain. Get the domain, and you get a handle — you can list it, age it, score it, watch its registration, spot the typosquat.
Here the attacker controls a path on somebody else's domain. There is no bad domain. No fresh-registration signal. No certificate anomaly. No lookalike string to catch. Nothing a domain blocklist can bite on.
That includes ours, and I would rather say it than imply otherwise: our domain blocklist would not have caught this, and neither would anyone else's, because there is nothing in it that is structurally distinguishable from a developer legitimately hosting a demo page on unpkg.
Blocking the mirrors is not the answer either. They are load-bearing infrastructure for the entire JavaScript ecosystem, and an organisation that blocks unpkg breaks a great deal of legitimate work to stop one phishing pattern.
What still works
The destination. The redirect has to land somewhere, and that somewhere is attacker-controlled, has a domain, and is blockable. The chain is only unblockable at the beginning. Defend at the end of it.
Egress and DNS filtering on the final hop catches this where URL reputation on the first hop cannot.
The behaviour, not the page. ClickFix ends by asking a human to do something — paste a command, run something, enter a credential. That request is the invariant. Every ClickFix variant we have covered this month, including the StopAndProtect operation running two thousand hacked WordPress sites, converges on the same final step, and it is the step worth training people on. The lure infrastructure keeps changing. The ask does not.
Reachability review for mirrors. If your developers need unpkg, fine. If your finance team's browsers can reach it, ask why.
The shape worth naming
We keep finding attackers moving down the trust stack rather than sideways along it. Not "how do I make my bad domain look good," but "whose good domain will host this for me, for free, and never know?" Hacked WordPress estates on Monday. Package-registry mirrors today. The vendor's own CAPTCHA widget embedded in the middle of it.
The common thread is that every trust signal being abused here is real. Real registry, real TLS, real CAPTCHA, real CDN. Nothing is forged, so nothing looks forged, and every control that works by detecting forgery has nothing to detect.
Sources
24 npm packages containing an identical malicious HTML page impersonating a Cloudflare verification screen, mirrored to unpkg and other services and used as redirect infrastructure to ClickFix-style phishing. Research by OX Security; reported by The Hacker News, BleepingComputer, Cybernews and others, 25–26 August 2026. The detail that the page embeds Cloudflare's legitimate Turnstile service and redirects regardless of verification outcome is from that reporting.
Capped at 95 percent: we hold no first-party observation of this campaign — no attributed indicators in our feed, and we have not independently verified the package count or the mirror behaviour. Our related ClickFix coverage (ReliaQuest's PowerShell-RAT cluster, May 2026; StopAndProtect, 24 August 2026) is our own.
If you run security awareness training, the slide that says "check for the padlock and verify the domain" needs a footnote now, and it is not a comfortable one. Both of those checks pass here. Rate this post below.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=they-published-24-npm-packages-that-nobody-was-ever-meant-to-install-the-package-was-never-the-weap
Comments