Phishing pages served from npm’s CDN infrastructure pass every check your security tools perform: the domains are years old, the certificates are valid, and the IP addresses host millions of legitimate requests daily. The problem isn’t a gap in your coverage. It’s a structural blind spot.
Security teams have spent years building detection systems around a simple principle: attackers who build their own infrastructure leave fingerprints that legitimate services don’t. Those fingerprints became the foundation of domain reputation scoring, email filtering, and network monitoring.
That model breaks when attackers stop building infrastructure and start borrowing it. Over the past year, campaigns have used the npm registry not to distribute malicious code but to host phishing pages— credential harvesting sites served through CDNs that appear on corporate allow-lists worldwide. Victims never install anything. They click a link in an email and land on a login page that loads from a domain their security stack has been trained to trust.
The structural advantage attackers have found
Traditional phishing infrastructure requires attackers to register domains, provision hosting, and obtain SSL certificates—each step creating detection opportunities that security tools have gotten good at exploiting. But services like jsDelivr and unpkg were built to solve a different problem: giving developers free, fast access to any file in any npm package without hosting costs. A package published to npm becomes available at predictable URLs within minutes, distributed globally through CDNs with valid certificates.
Attackers recognized what this means. Publish a package containing HTML and JavaScript instead of a library, and those files are instantly available through infrastructure that security tools have been trained to trust.
The campaigns that emerged in 2024 and 2025 weren’t experiments. One operation published 175 packages across nine accounts—no dependencies, no README files, no functional code. Just HTML and JavaScript designed to harvest credentials. A follow-up codenamed Beamglea did the same thing at even larger scale, targeting more than 135 organizations with Microsoft 365 phishing pages that arrived with the victim’s email address already filled in.
This is Living Off Trusted Sites in practice: attackers operating from platforms that security tools trust by default.
Why detection fails at multiple layers
What makes this evasion effective isn’t sophistication—it’s that the structural advantages defeat security tools at every layer of the stack, from email gateway to endpoint.
Email filtering relies heavily on URL reputation. When the link in a phishing email points to unpkg.com, the domain passes every reputation check. The email reaches the inbox.
Web proxies and secure web gateways categorize traffic by domain. CDN domains are categorized as “technology” or “content delivery”—categories that organizations can’t block without breaking developer workflows. The traffic flows through.
Endpoint detection looks for suspicious process behavior, malicious file writes, or known malware signatures. CDN-hosted phishing is pure HTML and JavaScript rendered in a browser tab. There’s nothing to detect on the endpoint.
Network monitoring watches for connections to known-bad infrastructure. But the connection goes to a globally trusted CDN—indistinguishable from a developer loading a legitimate library. The very infrastructure that makes modern software development possible is now providing cover for the attacks targeting it.
The persistence problem compounds the detection problem. Check Point researchers found that CDN caching means malicious content can remain accessible even after npm removes the offending package—in some cases, weeks later. The takedown at the registry level didn’t propagate to the CDN layer.
The economics that make this inevitable
For most of phishing’s history, attackers faced the same constraints as any infrastructure operator: domains cost money, hosting requires provisioning, and every component leaves a trail that eventually gets flagged. That friction created natural limits on campaign scale and longevity. Phishing built on npm operates under different economics. Publishing a package requires nothing but an email address, distribution happens automatically through CDNs that organizations can’t block without disrupting their own developers, and spinning up a replacement after a takedown takes far less time than the detection and response cycle on the defender’s side.
The scale reflects the advantage. Sonatype logged over 877,000 malicious packages across open source ecosystems by Q4 2025, with npm accounting for nearly all of them. Attackers have recognized what security teams are still catching up to: package registries offer infrastructure advantages that purpose-built phishing toolkits can’t match.
When phishing targets npm developers themselves
There’s an irony here. When phishing campaigns target npm maintainers themselves, successful credential theft enables the traditional supply chain attacks that dominate headlines.
The Shai-Hulud campaign that CISA issued an alert about in September 2025 began exactly this way: phishing emails impersonating npm support, credential harvesting pages that captured developer logins, and then automated abuse of those credentials to compromise legitimate packages. The self-propagating worm that followed, compromising over 500 packages in its first wave and 700+ more in November, represented the downstream consequence of successful phishing, not the initial attack vector.
The result is self-reinforcing: large-scale phishing harvests developer credentials, compromised credentials enable supply chain attacks, and each successful campaign funds the next.
The Bottom Line
The npm ecosystem has become dual-use infrastructure: a platform serving both legitimate software development and phishing operations optimized for evasion. The campaigns documented over the past year demonstrate that attackers view package registries not primarily as supply chain targets but as free, globally distributed hosting services that happen to enjoy universal trust.
Detection requires analyzing what content does, not where it comes from. Most security architectures aren’t built for that. The ones that adapt will; the ones that don’t will keep watching trusted domains deliver threats they were never designed to see.
Key Takeaways
The tools rely on infrastructure signals—domain age, IP reputation, certificate validity—that all read as clean when content is served from established CDNs. The phishing pages are hosted on the same domains and IP addresses as millions of legitimate developer resources.
Attackers publish packages containing HTML and JavaScript phishing pages instead of functional code. CDNs like jsDelivr and unpkg automatically serve these files. Victims never install the packages; they receive phishing links that load content from trusted CDN URLs.
Researchers documented 175 packages in one campaign and 175 more in a follow-up targeting 135+ organizations. Sonatype logged over 877,000 malicious packages by Q4 2025, with npm accounting for nearly all of them.
The relationship is sequential. Phishing campaigns that harvest npm developer credentials enable subsequent supply chain attacks. Shai-Hulud began with credential phishing before evolving into a self-propagating worm.
Content analysis of CDN traffic can identify patterns inconsistent with legitimate library usage. Organizations should monitor for packages containing HTML/CSS rather than JavaScript libraries. Behavioral analysis of what pages do—rather than where they’re hosted—becomes necessary when infrastructure signals fail.
