A link lands in someone’s inbox or chat window pointing to unpkg.com, the CDN that millions of developers use every day to pull JavaScript straight out of the npm registry. It looks exactly like what it claims to be, a file hosted by a service known for serving open-source code, not phishing pages. Click through and a Cloudflare CAPTCHA appears, styled convincingly enough to pass a glance. It is fake. Behind it sits a redirect chain built by an attacker who never had to register a lookalike domain, buy hosting, or send a single email that spoofed anyone. Researchers Moshe Siman Tov Bustan and Vitalii Chepurko at OX Security found 24 npm packages responsible for exactly this, all sharing one block of malicious code, none of them designed to infect a developer who installs them.
Publishing Malware as a Package Was Never the Point
Every one of the 24 packages was harmless to install. That was deliberate. The attacker’s real target was never a developer’s machine, it was the mirror network that automatically copies public npm packages onto other domains: unpkg, npmmirror, Yarn’s CDN, Tencent’s mirror. Publish a package containing an HTML file, and within hours that file is being served, byte for byte, from a domain with an established reputation and a TLS certificate nobody questions. Each package pulled 50 to 300 weekly downloads before npm caught on and pulled it, a lifespan short enough to dodge sustained scrutiny but long enough to serve thousands of page loads. The HTML itself renders a fake Cloudflare verification screen, the same social-engineering pattern used across the wider ClickFix family of attacks, which trick a visitor into pasting attacker-supplied commands into their own Run dialog or terminal. The specific redirect target is configurable after the fact, meaning today’s harmless-looking landing page can become tomorrow’s credential harvester or malware dropper without a new package ever being published.
DMARC Was Built to Answer a Question This Attack Never Raises
DMARC, SPF, and DKIM exist to answer one question: does the domain in the From header actually have the authority to send this message. None of that machinery activates here, because nothing about this attack requires impersonating a sending domain. The phishing page lives on unpkg.com, a domain the attacker never controls and never needs to spoof, since the CDN’s own mirroring behavior does the hosting for them. A link to it can travel by email, by Slack message, by a text, or by a comment on a public GitHub issue, and in every one of those channels it arrives looking exactly like ordinary developer traffic. Authentication protocols were designed around the assumption that a forged identity is the thing to catch. This technique never forges an identity at all. It borrows a real one that was never meant to host anything malicious in the first place.
The Open Registry Model Keeps Producing the Same Blind Spot
This is not the first time npm’s public, low-friction publishing model has been turned into free phishing infrastructure, and it will not be the last. A security researcher had already flagged a smaller version of the same trick in July, a single package using a fake Cloudflare page to redirect visitors elsewhere. What makes the pattern durable is structural: anyone can publish a package in minutes, mirrors copy that package’s contents automatically and without judgment, and takedown only removes the original, not every mirrored copy already circulating. A defender who blocks the original npm package while leaving unpkg.com’s mirror untouched has not closed anything. The registry’s openness is the feature that makes npm useful to millions of legitimate developers, and it is the exact same feature an attacker is exploiting here.
What This Means for Your Program
Do not extend automatic trust to CDN and mirror domains just because their reputation is old and their TLS is valid. unpkg.com, jsdelivr, and similar services are legitimate infrastructure that a determined attacker can still use as a hosting layer they never had to pay for or secure.
Treat this as a security awareness gap, not just a technical one. A fake CAPTCHA page hosted on a recognizable developer-facing domain will clear the mental bar that a link to a throwaway domain would trip. Train people to be suspicious of unexpected verification prompts regardless of where they are hosted.
Remember DMARC’s boundary is not a flaw, it is a scope. It authenticates who is allowed to send as a domain. It says nothing about what a link inside a legitimately authenticated message points to, or what page loads once someone clicks it. Link and content inspection has to sit alongside authentication, not instead of it.
If your organization publishes npm packages, monitor your own footprint on the major mirrors. A compromised or typosquatted package under your name gets mirrored just as automatically as a malicious one built from scratch, and the mirror copy can outlive your ability to pull the original.
The Takeaway
Twenty-four packages, one shared block of code, and a CDN doing exactly what it was built to do, mirror content quickly and reliably, added up to disposable phishing infrastructure that cost the attacker nothing and carried none of the reputational baggage a new domain would. DMARC was never going to catch this, not because it failed, but because the entire attack sits outside the question DMARC was built to answer. The lesson is the same one this pattern keeps teaching: authentication protects the envelope, not everything the envelope can point to.
DMARC tells you whether a domain had the right to send. It cannot tell you whether a link inside an authenticated message leads somewhere trustworthy. Excello Mail turns your DMARC aggregate reports into a clear, ongoing record of every service sending as your domain, so the part of your security posture that authentication actually covers never goes unwatched. Sign up for free to Excello Mail and keep that layer covered while your team handles the rest.