Executive Answer
In August 2026, researchers at OpenSourceMalware and Sonatype identified a coordinated campaign that published nearly 800 malicious packages to the npm registry. The packages used AI-generated names to mimic legitimate libraries and instructed developers to load them with require(), bypassing the install hook detection that most security tools rely on. The malware, called WEL1DROPPER, delivers a cross-platform RAT on Windows and Mac and the Sliver C2 framework on Linux. The attack targets developers in any country using Windows, Mac, or Linux. Most software composition analysis tools are configured to catch known malicious packages, not newly published unknown ones. This campaign exploits that gap.
- ~800 packages - Number of malicious packages published to npm in this campaign, per OpenSourceMalware. Sonatype's tracking under the name "Flooding Dropper" puts the count above 850.
- 3 platforms - Windows, macOS, and Linux all targeted with compatible payloads. WEL1DROPPER identifies the OS and architecture before fetching the appropriate payload.
- 3 Cloudflare Workers domains - Primary payload delivery infrastructure used by WEL1DROPPER. Falls back to DNS TXT record delivery via wel1[.]ru if HTTPS downloads fail.
- Sliver C2 - Open-source command-and-control framework deployed on Linux systems by this campaign. Originally a red team tool; now commonly seen in threat actor operations due to its detection evasion properties.
- ETW + AMSI - Windows monitoring capabilities patched by the malware before executing its payload. Event Tracing for Windows and the Antimalware Scan Interface are standard EDR feed mechanisms.
- August 7, 2026 - Date the campaign was publicly disclosed by OpenSourceMalware researcher Paul McCarty and Sonatype.
Your developers trust npm. Eight hundred packages published to that registry last week were built to exploit that trust, and they were designed specifically to avoid the controls most organizations have in place.
The npm registry hosts over 2.5 million packages. Developers install from it constantly, in CI pipelines, local development environments, and production build systems. The implicit assumption is that packages on npm are what they say they are, or at least that the tools watching the build process will catch the ones that are not.
This campaign was built to defeat that assumption.
How the Attack Works
OpenSourceMalware researcher Paul McCarty and the Sonatype security team independently identified nearly 800 malicious packages published to npm as part of a coordinated campaign. Sonatype is tracking it under the name "Flooding Dropper." The packages use AI-generated names that closely resemble legitimate libraries. Not obvious typos. Names that look syntactically and semantically correct at a glance.
Most npm supply chain attacks use lifecycle hooks, scripts that run automatically when a package is installed. This campaign does not. Instead, the malicious packages come with README files that instruct developers to load the package using require(), a standard JavaScript function for importing modules. The instruction looks normal. The tooling sees nothing unusual at install time.
When require() is called on the package, a downloader called WEL1DROPPER executes. It identifies the host operating system and CPU architecture, then contacts one of three Cloudflare Workers domains to retrieve a compatible payload. If the HTTPS connection fails, it falls back to DNS TXT records from wel1[.]ru, reassembling the payload from numbered TXT record chunks.
What Each Platform Receives
On Windows, WEL1DROPPER patches Event Tracing for Windows (ETW) and the Antimalware Scan Interface (AMSI) before anything else runs. ETW is the primary feed for most EDR tools. AMSI is the interface through which Windows security software inspects scripts and code at runtime. Patching both means the subsequent payload runs with reduced visibility from installed security software. The malware then establishes persistence through a Registry Run key and a scheduled task before downloading an encrypted secondary payload.
On Linux, the final stage is Sliver, an open-source C2 framework. Sliver was created for red team operations and is widely used by security professionals for legitimate penetration testing. Its traffic characteristics are not unique to any single threat actor, and its signatures are less consistent across deployments than commercial C2 frameworks. A developer machine running the Sliver agent is under full remote control: command execution, file transfer, network pivoting.
On macOS, the infection chain establishes a LaunchAgent for persistence and retrieves a compatible payload. The process mirrors the Windows chain: identify the environment, verify it is not a sandbox, establish persistence, and call home.
The packages also contain a file called lib/telemetry.js that implements what looks like a standard telemetry SDK. The package entry point does not import this file, but it contains the same downloader logic. The obfuscation adds another layer of deniability: the code looks like a legitimate but unused module.
Why Standard SCA Tools Miss This
Software composition analysis tools work in two primary ways: they check package names and hashes against known malicious package databases, and they scan for known vulnerability CVEs in dependency versions. Both approaches are retrospective. They catch threats that have already been identified and catalogued.
This campaign uses newly published packages with no prior malicious history. At the time a developer installs one of them, the package does not exist in any threat intelligence feed. An SCA tool scanning against known-bad lists sees nothing. A tool checking for CVEs in established packages sees nothing.
The attack also bypasses the lifecycle hook detection that some advanced SCA tools provide. By moving the malicious execution to require() rather than preinstall or postinstall scripts, the campaign avoids the trigger point that hook-aware scanners look for.
What would catch this: behavioral analysis of what packages do when require() is called, flagging packages with no download history or very recent publication dates, enforcing allowlists of approved packages for CI/CD pipelines, and monitoring developer endpoints for unusual DNS requests or unexpected process creation from Node.js processes.
The Business Risk
Developer machines are high-value targets. They have access to source code repositories, CI/CD pipelines, cloud deployment credentials, staging and sometimes production environments, and internal APIs. A developer machine under attacker control is a privileged position from which to move laterally into build infrastructure, sign malicious code with legitimate certificates, or exfiltrate proprietary intellectual property.
Financial services firms, healthcare organizations, and enterprise software companies all run development environments where a compromised developer machine could give an attacker access to regulated data or critical production systems. The entry point in this campaign, an npm package install, is not a sophisticated exploit. It is routine developer behavior that security programs rarely treat as a privileged operation.
What CISOs Should Address Now
Audit your SCA tool configuration. Verify that your software composition analysis tool flags packages with no download history or packages published within the last 30 days for additional review. If your tool only checks against known-bad lists, you have a gap for zero-day supply chain campaigns.
Implement package allowlists for CI/CD pipelines. Production build systems should only install packages from an approved list. New package additions should require explicit approval and review. This does not prevent developers from installing anything locally, but it prevents an accidentally installed malicious package from entering your build artifacts.
Monitor developer endpoints for post-compromise indicators. WEL1DROPPER makes outbound DNS and HTTPS connections to specific domains. Sliver C2 has characteristic traffic patterns. EDR tools on developer machines should alert on ETW or AMSI patching, unusual process creation from Node.js, and outbound connections to newly registered domains.
Review npm install access and developer permissions. Which developers can install packages without code review? Do your developers have access to production credentials on local machines? The damage a compromised developer machine can do depends heavily on what that machine has access to. Credential isolation and least-privilege principles for developer environments matter here.
Include open source package management in your third-party risk program. npm, PyPI, Maven, NuGet, and other package registries are part of your attack surface. The software supply chain risk framework should cover not just the vendors you contract with but the package ecosystems your development teams depend on daily.
Eight hundred packages is a scale that makes this qualitatively different from a targeted supply chain attack. A targeted attack goes after one specific library that a specific organization uses. Eight hundred packages cast a wide net. The attackers do not need to know who they are hitting. They need the probability that someone, somewhere in your development organization, will install one. Most third-party risk frameworks assess vendor security posture. They do not assess the package registries your developers use every day. That gap is not theoretical anymore.
Related Reading
Does your SCA tool flag packages with no download history? Do your developers have production credentials on local machines?
Let's Review Your Software Supply Chain ControlsSources
- OpenSourceMalware, Paul McCarty: "Russian AI Slopsquatting npm Campaign" (August 7, 2026): opensourcemalware.com/blog/russian-ai-slopsquatting-npm-campaign
- Sonatype: "Flooding Dropper Hits npm with 850 Malicious Packages" (August 2026): sonatype.com/blog/flooding-dropper-hits-npm-with-850-malicious-packages
- The Hacker News: "Nearly 800 Malicious npm Packages Deliver Cross-Platform RAT and Infostealer" (August 7, 2026)
Frequently Asked Questions
What is the WEL1DROPPER npm malware campaign?
WEL1DROPPER is a cross-platform malware downloader deployed through nearly 800 malicious npm packages published in August 2026. The campaign uses AI-generated package names to typosquat legitimate libraries, then instructs developers to load the packages with require() rather than using install hooks. The malware delivers a RAT on Windows and Mac, and the Sliver C2 framework on Linux.
Why did standard SCA tools miss these packages?
Most software composition analysis tools check packages against known-malicious databases and scan for CVEs in established dependencies. Newly published packages with no prior malicious history do not appear in these databases. The campaign also bypasses lifecycle hook detection by using require() instead of preinstall or postinstall scripts.
What is Sliver C2 and why is it used by attackers?
Sliver is an open-source command-and-control framework. Its traffic patterns can blend with legitimate activity, and because it is widely used for legitimate red team operations, its signatures are less unique than commercial C2 tools. Attackers use it because detection is harder and deployment is free.
What controls protect against npm supply chain attacks?
Key controls include: SCA tools that flag packages with no download history or recent publication dates; package allowlists for CI/CD pipelines; EDR monitoring for ETW and AMSI patching on developer machines; least-privilege credential management so developer laptops do not have production access; and treating open source package registries as part of the third-party risk program.