Before we get into the technical details, it's worth being clear about what this is and isn't. Everything we've covered in recent weeks (NGINX Rift, Dirty Frag, DirtyDecrypt) has been a flaw sitting quietly in legitimate software, waiting to be found and fixed. Flooding Dropper is different. It is not a bug in something you already trust; it is nearly 850 packages that attackers built and purposely published to the npm registry, specifically so that developers would install them. There is no patch for this. If a Flooding Dropper package made it onto a machine in your environment, the appropriate response looks a lot more like incident response than like a routine update.
npm is the package registry that the vast majority of JavaScript and Node.js projects pull their dependencies from. A developer adding a library to a project, a CI/CD pipeline installing dependencies to run a build, a container image being assembled: all of these routinely pull packages from npm, often dozens or hundreds of them, without a human reviewing each one individually. That's what makes a campaign like this dangerous. It doesn't need to trick a security team. It only needs to look plausible enough that an automated install step, or a developer moving quickly, pulls it in.
How this came to light
On August 5, 2026, researchers at OpenSourceMalware reported a malicious npm package called bigops-backend that delivered a platform-specific binary payload to Windows, Linux, and macOS systems. Sonatype Research Labs' Jorge Cardona recognized that this single package was part of something much larger. Sonatype is now tracking the campaign as sonatype-2026-005660 and has named it Flooding Dropper. At time of writing, Sonatype has identified 846 implicated packages, and OpenSourceMalware has since put the confirmed count at over 1,000, noting that new packages are still appearing, albeit at a slower pace than in the first days of the campaign.
Because this is a malware campaign rather than a disclosed vulnerability, there is no CVE number attached to it. Sonatype Guide classifies the malicious packages under CWE-506 (embedded malicious code), with an assigned CVSS score of 8.7.
What is Flooding Dropper?
Flooding Dropper is a large-scale npm supply chain attack. The threat actor is publishing packages, under many different accounts, that are designed to look like ordinary backend, payments, or SDK libraries. When installed and used, they deliver a downloader that fetches a remote access trojan (RAT) and infostealer onto the victim's machine.
The naming pattern
Rather than relying on a single prolific publisher, the operators behind Flooding Dropper appear to be automating account creation and package publication. Individual accounts publish only a handful of packages each, which denies defenders the shortcut of removing one account and calling the campaign contained. Many package names interpolate terms like "bigops" and "bnpl," producing names such as bigops-api or dolyame-boxy-desktop-bnpl-card-gallery. Version numbers frequently begin with a 35.x.y pattern. Researchers at OpenSourceMalware have separately described the naming approach as resembling AI-assisted, slop-squatted, or randomly generated typosquatting: names built to look like something a developer might reasonably search for or accept, rather than close copies of one specific well-known package.
Sonatype cautions that these naming conventions are a clue, not a durable detection control. Names and minor source-code details are trivial for an automated campaign to vary; the underlying delivery behavior is what stays consistent.
The install mechanism is unusual
Most npm-based supply chain attacks execute automatically, using lifecycle hooks such as preinstall or postinstall that run the moment the package is installed. Flooding Dropper packages don't do that. Instead, they ship with a README that instructs the developer to load the package using require(), the standard Node.js function for importing a module. That instruction, followed in good faith, is what triggers execution.
This is a meaningful shift in technique. Security tooling that specifically watches for suspicious install-time hook behavior may not flag a package whose malicious code only runs once a developer imports it as instructed.
What the downloader does
Once triggered, the loader (identified by researchers as WEL1DROPPER) behaves as a cross-platform staging mechanism:
- It checks environment variables and local state markers, likely to avoid re-running or to detect analysis environments.
- It identifies the host operating system and processor architecture.
- It attempts to download a matching binary payload from a randomized set of hardcoded Cloudflare Workers hosts.
- If the direct HTTPS download fails, it falls back to DNS TXT record delivery from the domain
wel1[.]ru. - It reassembles and decodes the DNS-delivered payload.
- It writes the resulting binary to a temporary directory, marking it executable on Unix-like systems.
- It launches the payload as a detached background process with output suppressed.
The Cloudflare Workers hosts observed so far are:
oob-worker.cf103-070.workers[.]devoob-worker.cf102-baf.workers[.]devoob-worker.cf99-9b3.workers[.]dev
The DNS fallback path uses platform-specific subdomains under wel1[.]ru:
- Linux x64:
sdk.dl.wel1[.]ru - Linux ARM64:
ext.dl.wel1[.]ru - macOS:
pkg.dl.wel1[.]ru - Windows:
net.dl.wel1[.]ru
The DNS TXT mechanism itself is worth understanding, because it's the more resilient of the two delivery paths. The malware first requests a TXT record from c.<domain> to learn how many payload chunks to expect (a value between 1 and 2,000). It then requests each numbered TXT record in turn, joins the returned strings together, and base64-decodes the result into a binary buffer. Because this only requires standard DNS queries, blocking the HTTPS download hosts alone does not stop delivery.
The detached-process step matters operationally: killing the npm install, or the parent Node.js process, does not stop the attack once the payload has launched. The downloaded binary keeps running independently.
The payload differs by platform
Windows. The downloaded binary is itself a loader for a further payload. Observed behavior includes patching Event Tracing for Windows (ETW) and the Antimalware Scan Interface (AMSI) to interfere with monitoring, checking for debuggers, virtual machines, sandboxes, and security products, copying itself into the user's AppData directory, and establishing persistence through both a Registry Run key and a scheduled task. It then downloads an encrypted payload from a remote /pkg/update_win.exe path, decrypts it, and reflectively loads it directly into memory rather than writing a conventional executable to disk and launching it, which makes the final stage harder for disk-focused security tooling to catch.
macOS. The infection chain performs a similar set of checks for debuggers and analysis artifacts before retrieving a payload from /pkg/beacon_mac.bin. If that fails, it falls back to the same DNS TXT delivery method, sets up persistence via a LaunchAgent, and starts the executable as a detached process.
Linux. The Linux payload is a UPX-packed ELF binary that downloads auxiliary payloads from a Cloudflare Worker URL, ultimately deploying Sliver, an open-source command-and-control (C2) framework that is popular with a wide range of threat actors because it is legitimate, actively maintained, and not inherently suspicious to flag on its own.
A decoy inside the package
Some of the packages contain a file named lib/telemetry.js that implements what looks like a plausible telemetry SDK, but which also contains the same downloader logic used elsewhere in the package. Notably, the package's actual entry point does not import this file, and researchers found no additional hardcoded infrastructure inside it. The working theory is that this oversized, unused file exists as camouflage: something that looks like ordinary analytics or profiling code to a developer skimming the package during a quick review.
Possible targeting signal
The macOS payload has been found to reference domains including tcsbank[.]ru and cloudpayments[.]ru, both associated with Russian financial and payments infrastructure. That doesn't mean every victim is being targeted for that purpose. It's most consistent with a financially motivated operation that has a specific fraud or account-takeover objective for certain victims, layered on top of broader, less targeted RAT and infostealer deployment against everyone else who installs an affected package.
Researchers have also suggested Flooding Dropper may be an evolution of Moika, an earlier dependency confusion campaign observed in April 2026 that published over 250 packages to steal environment information and deliver an OS-specific second-stage payload.
Who is at risk?
Realistically, anyone who installs npm packages is a potential target, but a few environments carry elevated exposure:
Developer workstations. Any engineer who added an affected package to a personal or project dependency list, or who followed a README's instructions to require() a package, is a direct risk. Standard code review does not always catch this, since the malicious behavior is designed to look unremarkable at a glance.
CI/CD pipelines and build agents. Automated dependency installation is exactly the workflow this campaign is built to exploit. A build agent that resolves and installs a Flooding Dropper package pulls the payload with no human in the loop at all, and CI/CD systems frequently hold credentials (cloud, source control, package registries) that are valuable to an attacker well beyond the build itself.
Internal package mirrors and caches. If a malicious package was cached or mirrored internally before detection, removing the public listing from npm does not remove it from your own infrastructure.
Container images and production-adjacent systems. Any image built from an affected dependency tree carries the payload forward into every environment that image is deployed to.
This campaign sits inside a noticeably busy period for open source supply chain attacks generally. Researchers at Unit 42 have documented several concurrent, unrelated campaigns across npm and PyPI in the same window, including packages delivering cryptocurrency stealers and RATs, and others aimed at cloud credential exfiltration, Solana wallet key theft, .env file secrets, and CI/CD credential theft via GitHub Actions. None of those are Flooding Dropper specifically, but they reflect the same broader pattern: the open source package ecosystem is currently a very active target.
What should you do?
1. Determine whether any Flooding Dropper package touched your environment
Sonatype is maintaining the current package list under sonatype-2026-005660 in Sonatype Guide, and OpenSourceMalware is tracking packages under the WEL1DROPPER identifier. Because the campaign is still actively publishing new packages under evolving names, a one-time check against a static list is not sufficient; treat this as an ongoing watch, not a single scan.
As a starting point, check dependency manifests and lockfiles for package names containing "bigops" or "bnpl," or for dependencies with version numbers in the 35.x.y range that you don't recognize as legitimate:
grep -riE '"bigops|"bnpl' package.json package-lock.json 2>/dev/null
grep -rn '"version": "35\.' package-lock.json 2>/dev/null
Treat a hit as a starting point for investigation, not a conclusion; the naming pattern will keep changing as the campaign evolves, and a clean grep result does not mean a host is clean.
2. If a package was installed, treat the host as compromised
This is the most important point in this whole article. Removing the malicious dependency from package.json is necessary, but it is not remediation. By the time the package is discovered, the downloaded binary may already have executed, established persistence, and be running independently of the npm process that fetched it.
For any system where an affected package was installed:
- Isolate the system and search for the documented persistence mechanisms (Registry Run keys and scheduled tasks on Windows; LaunchAgents on macOS).
- Review process, DNS, proxy, and endpoint telemetry for connections to the Cloudflare Workers hosts or the
wel1[.]rudomain family, including DNS TXT queries to subdomains beginning withc.. - Investigate any detached processes originating from Node.js, npm, or system temporary directories.
- Identify and capture any secondary executables or in-memory payloads before rebuilding.
- Remove persistence mechanisms and rebuild the affected system rather than attempting to clean it in place.
- Rotate npm, GitHub, cloud, and CI/CD credentials, but only after the environment has been cleaned; rotating credentials on a still-compromised host doesn't accomplish much.
- Review lockfiles, dependency caches, container layers, and internal mirrors for retained copies of the malicious package.
- Before reinstalling an intended replacement dependency, double-check the exact package name and spelling.
3. Watch for the technical indicators directly
Even without matching a specific package name, the delivery mechanism itself produces detectable network activity:
# Check DNS resolver logs for TXT queries to the wel1[.]ru domain family
grep -i 'wel1\.ru' /var/log/dns/*.log 2>/dev/null
# Check outbound connection logs for the known Cloudflare Workers hosts
grep -E 'cf103-070|cf102-baf|cf99-9b3' /var/log/proxy/*.log 2>/dev/null
A burst of numbered TXT record lookups to a single domain from a build agent or developer workstation is a strong signal worth alerting on, independent of which package triggered it.
4. Review your dependency intake process
Because this campaign specifically routes around install-time hook detection by asking developers to require() the package manually, controls that only watch for preinstall/postinstall script behavior will miss it. If you use a repository firewall or software composition analysis tool, confirm it evaluates package behavior at import time and not only at install time, and confirm it's ingesting current threat intelligence rather than a static allowlist or blocklist.
Detection
Like the malware-family issues we've covered before, this one leaves useful traces if you're watching in the right place, even though the initial install itself may look unremarkable.
# Look for suspicious detached child processes spawned from node or npm
ps -ef | grep -E 'node|npm' | grep -v grep
# Check for scheduled task or Run key persistence (Windows, via PowerShell)
# Get-ScheduledTask | Where-Object {$_.TaskPath -notlike "*Microsoft*"}
# Get-ItemProperty HKCU:\Software\Microsoft\Windows\CurrentVersion\Run
# Check for unexpected LaunchAgents (macOS)
ls -la ~/Library/LaunchAgents /Library/LaunchAgents
Repeated, unexplained outbound DNS TXT lookups from developer or build infrastructure, combined with any of the network indicators above, is the strongest available signal right now. File integrity monitoring alone won't help here since the payload is fetched and executed at runtime rather than shipped inside the package as a static file.
A note on the pace of this campaign
What makes Flooding Dropper worth tracking closely, beyond the immediate technical detail, is the operational model behind it. This isn't one prolific account that npm can suspend to shut the campaign down. It's automated account creation, automated package publication, and enough small variation between packages to blunt exact-signature detection, all running faster than manual moderation can keep pace with. Sonatype's own assessment is candid about this: package names and version patterns are useful correlation signals today, but they are not durable detection controls, because both are trivial for the operators to change as the campaign continues.
That's a pattern worth watching beyond this specific campaign. If your organization's dependency intake process leans on denylists of known-bad package names, it's worth treating that as one signal among several rather than the primary control.
Summary
| Campaign name | Flooding Dropper |
| Tracking ID | sonatype-2026-005660 |
| CVE? | None; this is a malicious package campaign, not a software vulnerability |
| Classification | CWE-506 (embedded malicious code), CVSS 8.7 (Sonatype Guide) |
| Discovered by | OpenSourceMalware (initial package), Sonatype Research Labs (full campaign scope) |
| Publicly reported | August 5, 2026 |
| Scale | 846 packages identified by Sonatype; 1,000+ confirmed by OpenSourceMalware as of August 11, still growing |
| Registry | npm |
| Trigger mechanism | Manual require() per README instructions, not install-time lifecycle hooks |
| Payload | Cross-platform RAT and infostealer (WEL1DROPPER loader); Sliver C2 on Linux |
| Delivery infrastructure | Cloudflare Workers hosts; DNS TXT fallback via wel1[.]ru |
| Persistence | Registry Run key + scheduled task (Windows); LaunchAgent (macOS) |
| Possible targeting | Indicators referencing Russian financial/payments infrastructure |
| Possibly related to | Moika dependency confusion campaign (April 2026) |
| Remediation | No patch; remove the package and treat the host as compromised (isolate, investigate, rebuild, rotate credentials) |
If you need help auditing your dependency trees for Flooding Dropper packages, investigating a host where one may have been installed, or tightening your package intake process against campaigns like this one, get in touch. A campaign that's still actively publishing new packages is not one you want to check for once and consider closed.