Researchers have uncovered a new phishing campaign leveraging 24 npm packages to serve fake verification pages via trusted mirror services rather than through direct package installations. Through contaminated HTML files in these packages, attackers are abusing popular mirrors to trick users into believing they’re interacting with legitimate verification screens, commonly branded as “ClickFix”.
The attack doesn’t require installing malicious software—instead, any HTML file hosted on mirrored package domains can be accessed like a webpage. When a user follows a link to such an HTML file, they’re presented with a phony Cloudflare-style CAPTCHA, which in turn contacts attacker-controlled infrastructure and redirects the user to pages designed for credential theft or malware distribution. Mirrors involved in this abuse include unpkg, Yarn, npmmirror, and Tencent mirrors. These services make package assets available directly rather than just as compressed bundles, allowing HTML files to render live pages.
Operation Details & Affected Packages
The campaign hinges on repurposing trusted hosting infrastructure: because these mirrors use recognizable domains, malicious content appears safer by proximity. The phishing page samples examined contain scrambled JavaScript and external logic that resolves to encrypted values before choosing a destination—sometimes genuine (e.g., ChatGPT), sometimes malicious. Even after compromised packages are removed from npm, the malicious files may remain accessible via mirrors. That makes mirrors key persistence points in this threat model.
In total, 24 distinct npm packages were identified. Many belong to a so-called Microsoft-typosquat family—names crafted to resemble Microsoft domains with subtle misspellings—while others are part of a “keyval new-logic” group exploiting legitimate key-value hosting services for redirects. The packages had weekly download counts ranging from about 50 to 300 before detection and deletion.
Protective Measures & Detection Strategies
Security teams are urged not to block mirror domains categorically, since these tools underpin legitimate development workflows. Instead, they should treat mirrored domains as potential phishing hosts whenever users access HTML files rather than packages. Incorporating mirror-hosted URLs into URL reputation systems can help spot weaknesses missed by conventional defenses. Proxy, DNS, and endpoint logs should be reviewed for direct requests to .html files within mirrored npm packages—especially when originating from unexpected sources like non-dev users.
Developers can limit risk by verifying package publishers and names, restricting access to unnecessary public mirrors, and educating teams to avoid running commands copied from untrusted sources—particularly verification prompts invoked through emails, tickets, or shared messages. Because mirrors may preserve malicious content even after the original npm package is taken down, what appears harmless could still be weaponized.
The broader takeaway: these attacks challenge basic assumptions about what package safety means. A dependency install might look clean, but the infrastructure around hosting—mirrors, domains, and auxiliary files—can be the real attack surface. Protecting against these threats will require defenders to expand their viewpoint beyond the package contents themselves and pay close attention to how they’re served.
What this means going forward is that mirror infrastructure—a well-intentioned convenience—is transforming into a point of fragile trust in supply chain security. Companies must rethink how they validate content from mirrored services, build guardrails around how verification steps are presented, and ensure that visibility into what files are being served lives at least as high as code review. Watch for broader adoption of mirror-monitoring tools, reputation filtering for static assets, and stronger education around social engineering tricks cloaked in familiar domains.
