Between late January and early February 2025, an automated malware campaign called "Flooding Dropper" released 850 malicious packages onto npm. Sonatype Research Labs is tracking this as sonatype-2026-005660. The campaign impacts 846 software components and uses version patterns in the 35.x.y range to evade detection while delivering second-stage payloads across Windows, macOS, and Linux systems.
This wasn't a targeted attack against a specific organization. It was an automated assault on the entire npm ecosystem, and it worked because the attacker automated faster than the defenders could respond.
Timeline of the Attack
The campaign's timeline reveals how automation overwhelms manual review processes:
Week 1 (Late January): Initial packages appear on npm using automated account creation. The malware uses version numbering in the 35.x.y range, likely to appear as mature, stable packages.
Week 2 (Early February): Package count reaches 850. Sonatype identifies the campaign and begins classification. The packages receive CWE-506 classification with a CVSS score of 8.7 (High severity).
Current State: Removal is ongoing, but the automated distribution mechanism makes complete eradication challenging. New variants continue to appear as the campaign adapts its evasion techniques.
The key insight: the attacker's automation cycle (create account, publish package, distribute) runs faster than manual security review and takedown processes.
Which Controls Failed
This incident exposed gaps in three critical control areas:
Package Registry Vetting: npm's automated publishing model allows any registered user to publish packages without human review. While this supports the open-source ecosystem's speed, it creates an attack surface when combined with automated account creation. The platform lacked behavioral analysis to detect coordinated publishing patterns from newly created accounts.
Dependency Scanning: Organizations using these packages had dependency scanning tools that relied on signature-based detection. The campaign's evasion techniques (obfuscation, multi-stage payloads, OS-specific execution) bypassed static analysis. Your scanner sees a package that imports legitimate libraries and executes what looks like normal JavaScript. It doesn't see the second-stage payload that downloads after installation.
Supply Chain Monitoring: Most teams track known vulnerabilities in dependencies through CVE databases. They don't monitor for suspicious package behavior: new packages with high version numbers, packages that execute platform-specific code during installation, or dependencies that make network requests to unusual domains. The campaign exploited this gap by automating behaviors that should have triggered alerts.
Standards and Requirements
Several standards address supply chain security, but they assume you're implementing behavioral controls, not just scanning for known vulnerabilities.
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom and bespoke software is reviewed prior to release. The requirement extends to third-party components: "All changes to software components are managed securely." If you're processing payment data and pulling in npm packages without behavioral analysis, you're not meeting this requirement. The standard expects you to understand what code does before it runs in your environment.
NIST Cybersecurity Framework (CSF) v2.0 includes supply chain risk management in the GOVERN function (GV.SC-02): "Suppliers are known and prioritized by criticality." When you npm install without verifying package provenance or monitoring installation behavior, you don't know your suppliers. The framework expects you to assess third-party risk continuously, not just at initial vendor selection.
ISO/IEC 27001:2022 Control 5.19 (Information security in supplier relationships) requires organizations to "define and agree information security requirements with each supplier." Your npm dependencies are suppliers. The control expects documented processes for evaluating supplier risk, which includes understanding how packages behave at installation time.
The standards share a common assumption: you have visibility into what third-party code does before and during execution. Static vulnerability scanning alone doesn't provide this visibility.
Lessons and Action Items
Here's what changes after Flooding Dropper:
Implement behavioral analysis for package installations. Configure your CI/CD pipeline to run new dependencies in a sandbox before they touch production. Monitor for network requests during installation, file system modifications outside the package directory, and execution of platform-specific binaries. Tools like npm audit don't catch this. You need runtime monitoring. If a package makes HTTPS requests during npm install, that's a detection signal worth investigating.
Version number inspection matters. The campaign used version 35.x.y to appear established. Your package review process should flag new packages (created in the last 90 days) that start with high version numbers. Legitimate packages build version history over time. A package created last week at version 35.0.0 deserves scrutiny.
Automate your own detection cycle. The attacker automated account creation and package distribution. You need to automate behavioral analysis at the same speed. Configure your dependency management system to reject packages that match risk patterns: new maintainer accounts, unusual installation scripts, dependencies that weren't in your last approved manifest. Make the automation work for defense, not just for development speed.
Map dependencies to business criticality. Not every npm package poses equal risk. Identify which applications process sensitive data (PCI DSS scope, PII, authentication credentials) and apply stricter controls to their dependency chains. A malicious package in a marketing site's build process is different from one in your payment processing API.
Document your supplier risk process. ISO/IEC 27001:2022 and NIST CSF both expect documented supplier assessment. Create a runbook that defines acceptable package behaviors, required vetting steps, and escalation paths when suspicious packages appear. Your auditor will ask for this. More importantly, your security team needs it when the next automated campaign hits.
The Flooding Dropper campaign succeeded because it automated faster than defenders responded. Your defense needs to match that automation with behavioral controls that run at installation time, not after compromise.
