npm Mirror Phishing via unpkg: Check If You're Exposed

Short answer: On August 25, 2026, OX Security disclosed a cluster of 24 malicious npm packages that abuse public npm CDN mirrors like unpkg.com as free, trusted-domain phishing hosting. The packages don't infect developers who install them — instead, each ships an index.html that, when served through a mirror, renders a fake Cloudflare "verify you are human" page and redirects visitors to credential-phishing and ClickFix infrastructure. If you consume npm packages by pulling raw files from unpkg or similar mirrors, or your brand's CDN domains are being laundered for phishing, this one matters. Here's how to check your exposure and lock the install boundary down.

What happened: 24 npm packages turned into phishing infrastructure

Most npm supply-chain attacks weaponize the install: a malicious preinstall hook fires when you run npm install and steals your credentials. This campaign is different, and that's exactly why it slipped past the usual defenses.

According to OX Security researchers Moshe Siman Tov Bustan and Vitalii Chepurko, the threat actor never intended to infect developers who install the packages. They used the npm registry and its mirrors as "free, validated storage for the malware." Every one of the 24 packages contains little more than an index.html file. When that file is requested through a CDN mirror — for example unpkg.com/<package>@1.0.0/index.html — the mirror renders it as a live, fully-functional web page hosted on a trusted, HTTPS-valid domain.

That page impersonates a Cloudflare security-verification screen and even embeds Cloudflare's legitimate Turnstile CAPTCHA widget to look authentic. Regardless of whether the "verification" succeeds, heavily obfuscated JavaScript executes and redirects the visitor to attacker-controlled infrastructure — typically a ClickFix-style fake-CAPTCHA lure or a credential-phishing page.

Why abusing npm mirrors is clever (and dangerous)

The trick works because it borrows trust the attacker never earned:

• Trusted domain + valid TLS. A phishing link on unpkg.com looks far more legitimate than a random typosquat domain, and it sails past URL-reputation filters.
• Free, resilient hosting. npm and its mirrors host the HTML at no cost, and packages can linger on mirrors even after removal from the official registry.
• Dynamic redirects via a "dead drop resolver." Initial versions redirected to Microsoft-login typosquat domains (login[.]microsofte[.]live, microcloud[.]homes). After Google blocklisted those, the actor pivoted to storing the current redirect target in api.keyval.org (the KeyVal key-value service), so they could swap the destination without republishing a package.

The technique was first spotted in July 2026 by researcher inf0stache, with IntelFusions also reporting on it; OX Security's August 25 write-up expanded it to the 24-package cluster. One named example package is china_airlines.

Am I exposed? How to check

Because this campaign doesn't rely on an install-time hook, the exposure question is different from a typical worm. Work through these:

1. Do you fetch package files directly from a mirror? Search your codebase and docs for hardcoded unpkg.com, cdn.jsdelivr.net, or similar mirror URLs — especially any that load raw .html from a package. Loading HTML from a package via a mirror is the red flag here.
2. Are any of these known IOCs in your logs or proxy history? Check web proxy, DNS, and email-security logs for: microcloud[.]homes, login[.]microsofte[.]live, and api.keyval.org (used as the redirect resolver).
3. Did anyone click a suspicious "Cloudflare verification" page reached from an npm/unpkg link? If so, treat it as a phishing exposure: rotate any credentials that may have been entered and review MFA/session activity.
4. Scan your dependency tree against advisory data. Run a free lockfile scan at installsafe.io/scan to check whether any package your project resolves is flagged as malicious in OSV.dev.

If you only ever install these packages through normal npm install — and none of them are in your tree — your developers aren't the target. But security teams and brand owners should still care: this pattern turns any trusted CDN into disposable phishing hosting, and your users may be the ones landing on the fake page.

Remediation steps

1. Block the IOCs. Add microcloud[.]homes, login[.]microsofte[.]live, and monitor/deny anomalous requests to api.keyval.org at your web proxy, DNS filter, and email gateway.
2. Stop loading raw HTML from package mirrors. Serve your own assets from infrastructure you control, or pin to a specific, reviewed artifact hash rather than a live mirror path.
3. Report abusive packages. If you find one of these HTML-only packages, report it to npm security so it's pulled from the registry (note that mirror copies may persist).
4. Rotate on suspicion. Anyone who entered credentials on the fake Cloudflare page should reset those credentials and revoke active sessions.
5. Screen new packages at the install boundary. Enforce a policy that blocks packages flagged as malicious in advisory data before they enter your registry, CI, or developer machines — see below.

How a registry firewall helps

A registry firewall sits between your npm install and the public registry, and it decides what's allowed through before a tarball ever lands on a developer laptop, a CI runner, or an AI coding agent's workspace. That install boundary is the natural place to enforce "known-malicious packages don't come in."

InstallSafe works as a drop-in registry proxy. Point npm at it once:

npm config set registry https://r.installsafe.io

From then on, every install is checked against OSV.dev advisory data, and versions flagged as malicious are blocked from being served — byte-for-byte tarball verification, across your CI and any AI agents that install packages on your behalf. In this specific campaign, the malicious packages are the delivery mechanism; keeping flagged packages out of your registry means they can't ride into your builds or be re-served from a mirror you operate.

An honest caveat: InstallSafe blocks packages that advisory feeds have already flagged — it is not a zero-hour, "catches everything at minute zero" claim. Behavioral-analysis tools like Socket, Snyk, and Aikido add value by flagging suspicious behavior before a CVE or advisory exists. InstallSafe's edge is form factor: a registry-level install boundary that covers CI and AI agents automatically, with no per-developer plugin to remember. Layer both, and pair them with the phishing-hygiene controls above — because a phishing-hosting campaign like this one is ultimately caught at the network and human layer, not just the dependency layer.

FAQ

Which npm packages are affected?

OX Security identified a cluster of 24 malicious packages; one named example is china_airlines. The full list is in OX Security's disclosure. The packages are HTML-only and designed to be served through mirrors, not installed as dependencies.

Do I get infected if I run npm install on one of these?

No credential-stealing install hook was reported for this campaign — the packages contain an index.html, not an install script. The danger is to people who visit the package's HTML through a mirror URL and land on the phishing redirect. Still, remove any of these packages from your project and report them.

What is unpkg and why does it matter here?

unpkg is a popular CDN mirror that serves any file from any npm package over a trusted, HTTPS domain. That's convenient for loading libraries in the browser — but it also means attackers can publish a package containing a phishing page and get it hosted, for free, on a domain that filters trust.

What are the indicators of compromise?

Known IOCs include the redirect domains microcloud[.]homes and login[.]microsofte[.]live, and the use of api.keyval.org as a dead-drop resolver storing the live redirect URL. The lure impersonates a Cloudflare Turnstile verification page.

How do I stop malicious npm packages from reaching my builds?

Enforce blocking at the install boundary with a registry firewall that checks every package against advisory data, and pair it with network/DNS filtering and phishing awareness. Start with a free scan of your lockfile at installsafe.io/scan.

Defensive advisory. Sources: OX Security (original disclosure, Aug 25, 2026), The Hacker News, BleepingComputer, and Snyk. Verify package names and IOCs against the primary advisory before acting.