Sonatype Research Labs is tracking an active malicious package campaign, dubbed 'Flooding Dropper,' spreading on npm, currently impacting 846 software components.
The attacker appears to be automating parts of the npm account and package creation process, combining terms such as bigops and bnpl with other words and recurring version patterns, such as releases in the 35.x.y range.
When installed, the packages download and execute a second-stage payload, using multiple delivery methods to improve the attack's chances of success.
Sonatype is tracking this campaign as sonatype-2026-005660. Impacted organizations should consider the host compromised, remove the package, investigate secondary payload execution and persistence, and rotate exposed credentials only after the environment has been cleaned.
On August 5, 2026, security researchers from OpenSourceMalware reported a malicious npm package named bigops-backend that delivered a platform-specific binary to Windows, Linux, and macOS systems.
Sonatype Research Labs' Jorge Cardona observed this package is part of a much larger, ongoing campaign. At the time of publication, Sonatype has identified 846 software components implicated in the campaign, dubbed 'Flooding Dropper.'
Rather than relying on a single publisher, the campaign generates npm accounts and publishes small numbers of packages from each one. Many package names interpolate terms such as bigops and bnpl, including examples resembling:
bigops-api
dolyame-boxy-desktop-bnpl-card-gallery
The packages also contain slightly modified payloads. While syntactically different, for example using different URL function and variable names, the packages all execute the same behavior. Those changes can reduce the effectiveness of detections that depend on exact signatures, even when the underlying behavior remains closely related.
The malicious packages contain code that runs when the package is installed or imported. The first-stage JavaScript acts as a cross-platform loader with several delivery paths.
Once executed, it:
Checks environment variables and local state markers to determine whether it should run.
Identifies the host operating system and processor architecture and selects a compatible Windows, Linux, or macOS payload.
Attempts to download the binary from a randomized set of hardcoded remote hosts.
Falls back to DNS TXT records if the direct HTTPS downloads fail.
Reassembles and decodes the DNS-delivered payload.
Writes the binary to a temporary directory and marks it executable on Unix-like systems.
Launches it as a detached background process with output suppressed.
Launching the payload in a detached process is an important failsafe because killing the npm installation process or parent Node.js process does not necessarily stop the attack. The downloaded binary can continue running independently in the background.
The DNS fallback is also significant. Blocking one download host may not prevent delivery when the malware can reconstruct the payload from TXT-record responses.
Initial analysis indicates the downloaded Windows binary is itself a loader for an additional payload. Once downloaded, Sonatype observed sophisticated downloader behavior, including:
Patching Event Tracing for Windows and Antimalware Scan Interface functions to interfere with monitoring and scanning.
Checking for debuggers, virtual machines, sandboxes, and security products and copying itself to a persistent location under the user’s AppData directory.
Establishing persistence through both a Registry Run key and a scheduled task.
Downloading an encrypted payload from a remote /pkg/update_win.exe path, decrypting it, and reflectively executing that payload in memory.
Reflective loading lets malware execute a payload without following the normal process of writing and launching a conventional executable from disk. That can make the second stage harder for disk-focused security controls to detect.
Publishing malicious packages at scale is not new. Distributing them across many disposable accounts makes containment harder.
The Flooding Dropper threat actors are using account names that appear randomly generated, and individual accounts publish only a handful of packages. That prevents defenders from assuming that removing one prolific publisher will eliminate the broader operation.
It also creates a moderation problem for npm. Each account and package may need to be identified, reviewed, and removed independently while the attacker continues generating more.
The campaign's naming convention is already evolving. While many packages contain "bigops" or "bnpl," Sonatype Research Labs observed additional packages using different names. Many also share version numbers beginning with 35.x.y, providing another point of correlation. These characteristics help identify related packages today, but they are not durable detection mechanisms — both can change as the campaign evolves.
Automation changes the economics of open malware campaigns. Attackers can rapidly generate many accounts, publish slightly modified packages, and create enough variation to frustrate simple deny lists.
Organizations should first determine whether any package listed under sonatype-2026-005660 was downloaded or installed in developer workstations, CI/CD runners and build agents, internal repositories or caches, test systems, or production-adjacent infrastructure.
Removing the dependency is necessary, but not sufficient. By the time a malicious dependency is discovered, the package itself may no longer be the main problem.
Affected hosts should be treated as compromised:
Isolate systems where affected packages were installed and search for documented persistence mechanisms and IoCs.
Review process, DNS, proxy, and endpoint telemetry for payload retrieval.
Investigate detached processes originating from Node.js, npm, or temporary directories.
Identify any subsequent executables or in-memory payloads.
Remove persistence and rebuild affected systems when appropriate.
Rotate npm, GitHub, cloud, CI/CD, and other developer credentials after remediation.
Review lockfiles, dependency caches, container layers, and internal mirrors for retained copies.
Reconfirm package names and dependency spelling before installing intended replacements.
Sonatype Guide classifies the affected packages under CWE-506 with a CVSS score of 8.7.
The early bigops and bnpl naming conventions helped connect this campaign. They should not become the only thing defenders look for.
Attackers can change names more easily than they can change the purpose of their malware. The same is true of minor source-code modifications intended to avoid exact signature matches. A blocklist of known names can help with yesterday's packages; behavioral and similarity analysis are what help find tomorrow's variation.
Sonatype Research Labs will continue tracking this campaign under the identifier sonatype-2026-005660 as new packages, infrastructure, and payload details emerge.