Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: A fake Cloudflare Captcha campaign in npm reused identical malicious HTML across 24 packages and leveraged mirrors such as unpkg and yarn to host trusted-looking phishing pages, with each package drawing 50 to 300 weekly downloads before removal, according to OX Security Platform. The pattern shows how package ecosystems can be abused as delivery and storage infrastructure, not just as malware distribution channels, and why identity and URL trust controls now need to cover developer tooling.
NHIMG editorial — based on content published by OX Security Platform: fake Cloudflare Captcha campaign in npm mirrors
By the numbers:
- Each package usually reached between 50 and 300 weekly downloads before it was removed.
- The campaign included 24 distinct malicious packages sharing the exact same malicious code.
Questions worth separating out
Q: How should security teams handle trusted package mirrors that serve HTML pages?
A: Security teams should treat package mirrors that render HTML as potential phishing hosts, not just as dependency distribution endpoints.
Q: Why do package mirror abuse campaigns create more risk than simple malicious packages?
A: They create more risk because the browser, not the installer, becomes the execution and trust boundary.
Q: What do organisations get wrong about npm supply chain attacks?
A: They often focus on package provenance while underestimating runtime behaviour and local secret exposure.
Practitioner guidance
- Classify mirror domains as phishing infrastructure Add unpkg, npmmirror, yarn, tencent, and similar mirror domains to phishing detection, URL reputation, and browser protection rules when they serve rendered package files.
- Search for direct HTML access in proxy and DNS logs Look for direct .html requests to mirrored package paths, especially when the request lands on a trusted mirror domain rather than the source registry.
- Tune developer browser controls for package-based lures Block or warn on browser navigation to package mirror content when the file type is HTML, because installation safety does not equal browsing safety.
What's in the full article
OX Security Platform's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact package names, publication timestamps, and takedown status across the full 24-package cluster
- IOC details for the typosquatted Microsoft domain, the api.keyval.org redirect flow, and the packaged HTML payload
- The HTML and JavaScript logic that drives the fake verification page and remote redirect decisions
- Package-by-package mirror exposure examples that show how the same content appears on unpkg and other mirror services
👉 Read OX Security Platform's analysis of the fake Cloudflare Captcha npm campaign →
npm mirror abuse and fake captcha pages: are your controls keeping up?
Explore further
25/08/2026 6:11 pm
Trusted developer infrastructure is becoming a phishing layer. When package mirrors render HTML directly in the browser, the trust boundary moves from software intake to web delivery. That means an npm package can behave less like a dependency and more like a hosted lure, especially when mirrors preserve the content after removal from the source registry. For identity and access teams, the lesson is that trust decisions must extend beyond signing and install controls to the browser paths developers actually follow.
A question worth separating out:
Q: What should teams do immediately when a mirrored package starts serving malicious content?
A: Contain the exposure by blocking the mirror path at web and proxy layers, preserving logs for direct file requests, and checking whether developers or CI systems opened the HTML payload. Then verify whether the same content persists on mirrors after registry removal, because takedown alone may not end the campaign.
👉 Read our full editorial: npm mirrors as phishing infrastructure: why this campaign matters
