What Happened
OX Security discovered 24 npm packages containing malicious HTML pages designed to impersonate Cloudflare's security verification interface. The attack didn't target developers' machines directly. Instead, threat actors uploaded packages containing HTML files that, when accessed through npm mirrors like UNPKG, served as fully functional phishing pages. These pages redirected victims to attacker-controlled websites after presenting what looked like a legitimate Cloudflare CAPTCHA challenge.
The attack exploits a fundamental characteristic of npm mirrors: they serve package contents as web-accessible files. Upload an HTML file in a package, and the mirror becomes your free hosting platform. No malware installation required. No developer machine compromise necessary. Just persistent, publicly accessible phishing infrastructure hiding in plain sight.
Timeline
We don't have specific dates for when these packages were uploaded or how long they remained active. What we know:
- OX Security identified 24 malicious packages
- The packages contained HTML files mimicking Cloudflare's interface
- The HTML pages were accessible through npm mirrors
- The pages redirected users to attacker-controlled domains
The absence of a detailed timeline is itself instructive. These packages could have existed for weeks or months before detection. Your current monitoring likely wouldn't have caught them either.
Which Controls Failed
Package Content Validation
npm's automated scanning focuses on executable code. An HTML file doesn't trigger malware signatures. It's not a backdoored dependency. It's just markup. Your SAST tools scan JavaScript, not static HTML served through a mirror. The malicious packages passed automated checks because those checks weren't designed to detect this attack pattern.
Mirror Usage Governance
Most teams don't track which mirrors developers use or what gets accessed through them. You might have policies about approved package sources, but do you monitor what your team accesses through UNPKG, jsDelivr, or other CDN-style mirrors? The attack succeeded because mirrors operate as trusted infrastructure with minimal oversight.
Phishing Detection at the Perimeter
Your email filters and web proxies look for phishing domains. They don't flag npm mirror URLs. The malicious HTML was served from unpkg.com, a legitimate domain. Traditional perimeter defenses treat these requests as developer activity, not potential phishing vectors.
Supply Chain Visibility
You probably have a software bill of materials (SBOM) process. You track dependencies. But do you track non-executable files in packages? Do you monitor what gets served through mirrors versus what gets installed locally? The gap between "packages we install" and "package content accessible through mirrors" created the blind spot.
What Standards Require
NIST Cybersecurity Framework v2.0
The Govern (GV) function requires you to understand your cybersecurity supply chain risks (GV.SC-01). That includes understanding how package infrastructure can be abused. The Identify (ID) function calls for asset management that extends to external dependencies (ID.AM-02). Your mirrors are part of your attack surface.
NIST 800-53 Rev 5
Control SR-3 (Supply Chain Controls and Processes) requires organizations to employ acquisition strategies and contract tools to protect against supply chain risks. When you use public npm mirrors, you're incorporating third-party infrastructure into your development workflow. SR-6 (Supplier Assessments and Reviews) applies here too. Have you assessed UNPKG's security posture? Probably not.
OWASP ASVS v4.0.3
Section 14.2 covers dependency management. Requirement 14.2.1 states that all components should come from pre-defined, trusted, and continually maintained repositories. If your developers can access arbitrary packages through mirrors without approval, you're not meeting this requirement. Requirement 14.2.3 requires maintaining an inventory of third-party components. Does your inventory include HTML files served through mirrors?
Annex A control 5.19 (Information Security in Supplier Relationships) requires you to define and agree upon information security requirements with suppliers. npm mirrors are suppliers in your development chain. Control 8.30 (Outsourcing) applies when you rely on external infrastructure for package delivery.
Lessons and Action Items
Implement Mirror Access Controls
Don't let developers access arbitrary content through public mirrors. Set up an internal mirror or proxy that logs requests and validates content before serving it. This isn't about blocking mirrors entirely. It's about visibility and control.
Action: Configure your network to route all npm mirror requests through a logging proxy. Start with read-only monitoring for two weeks to understand usage patterns, then implement content validation rules.
Expand Package Scanning Beyond Code
Your current scanning tools look for malicious JavaScript. You need to scan all package contents, including HTML, CSS, and configuration files. An HTML file in a package should trigger review, especially if it contains forms or external redirects.
Action: Add a policy check to your CI/CD pipeline that flags packages containing HTML files. Review each flagged package manually until you've established baseline patterns for legitimate use cases.
Monitor Mirror-Served Content
Track what gets accessed through mirrors separately from what gets installed locally. A package that's never installed but frequently accessed through a mirror deserves investigation.
Action: Set up logging for all requests to npm mirror domains. Alert on packages that generate HTTP requests but don't appear in your package-lock.json files.
Update Your SBOM Process
Your software bill of materials should include non-executable files that could be weaponized. If a package contains HTML, that's a potential attack vector even if the JavaScript is clean.
Action: Modify your SBOM tooling to flag packages containing web-servable content (HTML, CSS, SVG). Include mirror-accessible files in your dependency reviews.
Test Your Phishing Defenses Against Trusted Domains
Run a red team exercise where you host a phishing page on a legitimate developer infrastructure domain. See if your controls catch it. They probably won't.
Action: Create a test HTML file in a private npm package. Access it through UNPKG. Check whether your web proxy, SIEM, or email filters flag the domain. Document the gaps.
The npm mirror attack works because it exploits the space between "developer tool" and "web host." Your security controls treat these as separate categories. Threat actors don't.
