The Package Wasn’t the Payload. Its Trusted Mirror Was the Phishing Site.
Attackers published 24 npm packages not to infect developers who installed them, but to make their HTML files available through trusted package mirrors. A victim who opened the mirrored file in a browser saw a fake verification page on a legitimate CDN domain before being redirected elsewhere.
OX Security’s research changes the usual npm incident model. The packages did not execute an infostealer during installation. The registry and its mirrors were being used as free, reputation-laundered web hosting.
A software mirror became a browser origin
Services such as UNPKG, npm mirrors, Yarn mirrors and other package-delivery infrastructure make registry content easy to retrieve. Some expose individual files directly instead of serving only a compressed package archive.
That feature is useful for JavaScript libraries, stylesheets and other web assets. It also means an HTML file inside a package can be rendered as a page under the mirror’s domain.
The malicious packages contained a shared HTML page that impersonated a Cloudflare-style verification step and embedded the legitimate Turnstile service. Regardless of whether the check succeeded, obfuscated JavaScript could redirect the visitor to a destination selected by the attacker.
To a reputation-based security product, the first URL can look reassuring. The domain belongs to a widely used developer service, uses HTTPS and may already be allowlisted. The suspicious content is hidden deeper in the path.
Installing the package was not the trigger
This distinction is operationally important. OX Security found no harmful installation behavior in the analysed packages. A developer who downloaded one did not automatically execute malware simply because it entered a dependency directory.
The risk appeared when a user visited the HTML file through a mirror that rendered it in a browser. The package registry supplied storage and replication. The mirror supplied a trusted origin. The attacker supplied the link and redirect logic.
That makes this campaign different from ChainDrop, where malicious package releases executed during installation and stole credentials that helped the worm propagate. Both operations abuse trust in the npm ecosystem, but they attack different consumers and controls.
| Campaign | Trigger | Primary victim | Trusted component abused |
|---|---|---|---|
| ChainDrop | Package installation lifecycle | Developer workstation or CI environment | Publishing rights and dependency installation |
| Mirror-hosted phishing | Opening a package HTML file in a browser | Any user receiving the link | Registry storage, mirror replication and domain reputation |
The redirect destination could change without republishing
Earlier campaign versions redirected to attacker-controlled domains including a Microsoft-themed typosquat. Later packages queried the legitimate api.keyval.org service, retrieved an encrypted value and used it to determine the next destination.
This created a dead-drop resolver. The actor could change where victims were sent without updating the npm package or changing the trusted mirror URL. At the time of OX Security’s analysis, the remote configuration led to the legitimate ChatGPT site. The researchers warned that it could be changed to a phishing page or ClickFix delivery path.
That evidentiary limit matters. The package set provides live redirect infrastructure and a demonstrated fake verification page. It does not prove that every visit resulted in malware execution or credential theft. The configuration can be dormant, benign-looking or malicious at different moments.
Removal from npm may not remove every copy
A package deleted from the primary registry can remain accessible through caches or third-party mirrors. The infrastructure that improves availability also distributes the takedown problem.
OX Security listed 24 packages in the cluster. Several had been removed by the time of publication, while others were still live. Typical packages accumulated between 50 and 300 weekly downloads before removal, but those download figures are not a victim count. The campaign was designed around browser visits, not package installation.
What defenders should change
- Treat direct browser requests for
.htmlfiles on package mirrors as a distinct security signal. - Add package-mirror URLs to phishing inspection and URL-reputation pipelines instead of trusting the domain as a whole.
- Review proxy and DNS logs for mirror paths that end in HTML pages and are followed by redirects to unrelated domains.
- Separate developer access requirements from general user browsing. If a mirror is needed for builds, that does not mean every endpoint needs unrestricted browser access.
- Inspect the full URL path in messages and alerts. A trusted host does not make an arbitrary package name or file path trustworthy.
- Preserve redirect chains and fetched content during incident response, because the final destination can change after the original event.
Package security controls often ask whether code runs when software is installed. This campaign asks a different question: what else can a public registry make reachable under a domain everyone already trusts?
Sources and further reading
- OX Security, ClickFix Phishing Pages Discovered in 24 npm Packages, published 25 August 2026. The source provides no publication time.
- BleepingComputer, Hackers abuse npm mirrors to host phishing redirect pages, published 25 August 2026 at 5:39 PM. The page does not state a timezone.
