846 Malicious npm Packages: Why the Flooding Dropper Campaign Poses Risks to Scraping Teams

On August 5, 2026, Sonatype researchers recorded a campaign in npm dubbed Flooding Dropper: 846 malicious components uploaded from dozens of disposable accounts. A week later, the count rose — updated data from OpenSourceMalware, tracking the same campaign under the name WEL1DROPPER, now lists 1,033 confirmed packages. Inside, there is a cross-platform loader that pulls the second stage on Windows, macOS, and Linux, wiping everything it can reach from the developer's machine: environment variables, credentials, sessions.

For teams that rely on parsing and automation, this is not "just another npm news." The scraping stack is precisely npm: Playwright, Puppeteer, Crawlee, wrappers over proxy agents, HTML parsers, queues. And on the same machine where all this is installed by one team, there usually lies a .env file with the login and password for the proxy pool, a cookie-jar for sessions, and profiles for anti-detect browsers. Let's break down what exactly happened and what practical implications arise from it.

What is known about the campaign

Sonatype is conducting the campaign under the identifier sonatype-2026-005660 with a CVSS score of 8.7 and a CWE-506 classification (injected malicious code). The characteristic signs by which researchers linked the packages into one group include:

• Automatic name generation. Names are created by interpolating repeating terms — the report mentions "bigops" and "bnpl," with examples like bigops-api and long concatenations such as dolyame-boxy-desktop-bnpl-card-gallery. OpenSourceMalware describes this as "AI slop squatting" — mass type-squatting with randomly generated names instead of neatly mimicking a single popular package.
• Versions from a single range. Releases cluster around 35.x.y — unusually high numbers for packages without a history.
• Spread across accounts. Each account publishes a small batch of packages, so blocking one publisher does not cripple the operation.

The mechanics of the launch are described differently, and this difference is important. Sonatype states that the code triggers "upon installation or import" of the package. OpenSourceMalware clarifies: some samples bypass classic lifecycle hooks and require the developer to manually include the package via require(). The practical takeaway is this: relying solely on --ignore-scripts will not save you — if the dependency is actually imported into the code, the payload will execute.

How the second stage is delivered

The loader pulls the payload over HTTPS from a random host from a hardcoded list — according to The Hacker News, the delivery points were three domains on Cloudflare Workers. If the direct download fails, a backup channel kicks in: the payload is assembled from DNS TXT records of the domain wel1.ru with platform subdomains (sdk.dl, ext.dl, pkg.dl, net.dl). This means that an outgoing filter for HTTP domains is bypassed by regular DNS queries — and very few cut those in a corporate network.

Next, the platforms:

• Windows: ETW and AMSI are patched (i.e., telemetry and antivirus checks for scripts are silenced), persistence is achieved through autostart registry keys and scheduled tasks, files in AppData.
• macOS: the same evasion techniques, persistence through LaunchAgent. In the macOS payload, researchers found domains of Russian financial services (tcsbank.ru, cloudpayments.ru) — a sign of targeted interest in banking sessions of Russian-speaking users.
• Linux: a packed UPX ELF binary that deploys a Sliver framework agent — this is a full-fledged C2 channel, not just a one-time theft.

Plus the standard set: sandbox checks and debuggers, architecture detection, reading environment variables, detached background processes (survive terminal closure), and reflecting the payload in memory to avoid leaving a file on disk.

Why this specifically targets parsing teams

The infostealer does not distinguish between "important" and "unimportant" — it collects everything that looks like a secret. For an average user, this includes passwords from browsers and crypto wallets. For someone involved in data collection, the trophy set is different and, frankly, more appealing:

• Environment variables and .env — this almost always contains the proxy gateway host, login, password, and session parameters (country, city, sticky identifier). Exfiltration of environment variables is explicitly mentioned in the campaign analysis.
• Cookies and session tokens. A stolen session bypasses MFA: a cookie itself is proof that the second verification has already been passed. Logs with valid tokens for working services are sold on shadow marketplaces starting at $5.
• Profiles of anti-detect browsers — a combination of "cookie + fingerprint + proxy," meaning a ready-to-use account that does not need warming up.
• CI/CD, npm, and cloud tokens — access not only to your machine but also to the pipeline, from which your builds can be sent out.

The scale of the phenomenon has ceased to be niche. SpyCloud's 2026 report counted 18.1 million exposed API keys and tokens obtained specifically from malware logs. According to Recorded Future and Flashpoint, in 2025, infostealers infected 11.1 million machines and provided 3.3 billion stolen accounts. And in Sonatype's report on the state of the software supply chain for 2026, more than 454,600 new malicious packages were recorded in just one year (2025), accumulating over 1.233 million blocked — a 75% year-on-year increase. Flooding Dropper is not an anomaly but a regular episode in the stream.

What the owner of a proxy account loses

I want to specifically address what is usually not mentioned in security analyses because the authors do not work with proxies. Leaked proxy credentials are not just a "password loss," but three problems at once:

1. Paid traffic. Residential and mobile traffic is billed by the gigabyte. A foreign parser using your credentials means your bill, and you may notice it much later than you would like.
2. Someone else's reputation on your IPs. An attacker needs a "clean" residential exit for their activity to appear as that of an ordinary home user. Your target sites will see suspicious behavior in your session — and bans will hit accounts that you have been warming up for years.
3. Dealing with the provider. From the perspective of any normal provider, the traffic was coming from your account, and you will have to explain yourself.

What to do: practical minimum

1. Separate environments. The scraping stack should be installed in a container or separate VM — not on the machine where personal cookies, work emails, and production tokens are stored. This is the only measure that works even against a package that no one knows about yet.
2. Remove proxy credentials from .env next to the code. Secrets should go into a secrets manager or the runner's environment variables, not into a file in the project root that any imported module can read.
3. Enable IP authorization where available. Tying access to your server devalues stolen login/password pairs: they simply won't work from someone else's address. How this is set up and in which scenarios it fits was discussed in the material on whitelisting IP addresses for proxies. General rules for storing access credentials can be found in the guide on secure storage of proxy credentials.
4. Separate sub-credentials for each project and traffic limits. If each script has its own access with a ceiling on gigabytes, leaking one will not drain the entire balance and can be localized within minutes.
5. Monitor consumption. A sudden spike in GB usage without an increase in tasks is the earliest and cheapest detector of compromise you have.
6. Discipline with dependencies. Use npm ci based on the lock file instead of a free install, quarantine new versions (7–14 days), check the age of the package and the publisher's history, and maintain an internal mirror with an allowlist. A package with version 35.x.y, zero history, and a name made of concatenated words is a reason to stop, not install.

If you suspect you have already been compromised

Sonatype's recommendations here are extremely specific, and the order is crucial: consider the host completely compromised; look for the described persistence mechanisms (autostart keys and scheduled tasks in Windows, LaunchAgent in macOS); rotate credentials — npm, GitHub, cloud, CI/CD — after cleaning the machine, not before, otherwise new secrets will leave via the same route; check lock files, dependency caches, and internal mirrors for any remaining copies; before reinstalling, compare package names character by character.

To this list, add your own: change passwords for proxy access, revoke active sessions in the anti-detect browser, and check traffic consumption history for the last two weeks. If traffic is purchased by gigabytes — residential or mobile proxies — the report on consumption is your access log.

Conclusion

Flooding Dropper is interesting not for its sophistication but for its economics: a thousand disposable packages, generated names, accounts in batches — this is a conveyor designed for someone to install a dependency without looking. Individual campaigns will clean the registry for weeks, but the stream will not stop: Sonatype's figures from last year leave no illusions.

The practical takeaway for those collecting data is simple. The developer's machine is the point where all your accesses converge at once: proxies, accounts, sessions, pipeline. Isolate the stack, tie accesses to IPs, distribute credentials across projects, and monitor traffic consumption. None of these steps require waiting for the next campaign to be indexed.