846 malicious npm packages: audit what your build installs

Someone built a factory for supply chain attacks. Sonatype Research Labs published details on 846 malicious npm packages from a single automated campaign it calls Flooding Dropper — disposable accounts, machine-generated names, and a cross-platform payload that runs on Windows, Linux, and macOS. The interesting part is not the malware. It's that the entire publish pipeline appears to be automated, which changes what "audit your dependencies" has to mean.

What actually happened

Per Sonatype's writeup (published August 5, tracked as sonatype-2026-005660, rated CVSS 8.7 under CWE-506), the operators appear to be automating npm account creation and package publishing, with each throwaway account pushing a small number of packages. Names are interpolated from term lists — bigops-api, dolyame-boxy-desktop-bnpl-card-gallery — and many share version numbers starting with 35.x.y, which is the cleanest correlation signal defenders have.

The malicious JavaScript executes on install or on import. The first stage fingerprints OS and processor architecture, pulls a platform-specific binary over HTTPS, and falls back to DNS TXT records if the HTTPS fetch fails — then launches the payload as a detached background process. On Windows the second stage patches Event Tracing and antimalware interfaces, checks for debuggers, VMs, sandboxes, and security products, persists via a Registry Run key and scheduled tasks, and executes encrypted payloads reflectively in memory.

The Hacker News reported the same campaign at a slightly lower package count and added that Sliver command-and-control gets deployed on Linux hosts. We'll note one discrepancy and leave it: that report describes README instructions nudging developers to require() the package, while Sonatype's own analysis says the code fires on normal install or import with no such trick. Sonatype found it; we're going with Sonatype.

Why your CI runner is the real target

A developer laptop is bad. A CI runner is worse, and that is where most of these detonate. Your build agent has the npm token, the GitHub token, the cloud deploy credentials, and the registry push rights. It runs npm install unattended, dozens of times a day, on a box nobody watches. A detached background process starting from a Node build step is invisible unless you already decided to look.

The DNS TXT fallback is the detail worth sitting with. If your only egress control is an HTTPS proxy allowlist, this campaign routes around it — and DNS is the one protocol almost nobody filters on a build runner.

What actually helps, none of it exotic. Pin and commit lockfiles, and make CI install from the lockfile only, so a typo-squat can't resolve in on a fresh build. Log DNS from your build network, not just HTTP, because that's where the fallback channel lives. Give CI short-lived scoped tokens instead of long-lived org-wide ones, so a compromised runner expires on its own. And check your lockfiles for the 35.x.y version pattern and anything you don't recognize — Sonatype's remediation guidance is blunt about the rest: isolate, hunt persistence, rebuild, then rotate npm, GitHub, cloud, and CI/CD credentials in that order.

The old advice was "vet your dependencies." When a machine can mint 846 packages, vetting by name doesn't scale. Constraining what a build is allowed to do does.

Sources: Sonatype Research Labs, The Hacker News.