What is the Flooding Dropper campaign
In early August 2026, security researchers at Sonatype flagged a sprawling npm campaign they named Flooding Dropper. The attack publishes close to 850 malicious packages to the public npm registry, and it is far more than a lone typosquatting mistake. The packages are built to run code the moment they are installed or imported, dropping a cross-platform remote access trojan on Windows, Mac, and Linux developer machines.
The real payload ultimately connects back to a Sliver command-and-control server. Sliver is a well-known open-source adversary emulation framework, which means operators can run multi-platform implants, pivot across hosts, and maintain stealthy persistence. For an everyday DevOps or Node.js developer, a single bad dependency can become a silent backdoor into their laptop and, from there, into CI/CD credentials.
Why scale changes the game
The tired advice was simple: block known malicious package names and move on. Flooding Dropper ignores that playbook. The attackers use account names that look randomly generated, and each account publishes only a handful of packages. That structure means removing one prolific publisher does nothing to stop the broader operation. The campaign is automated end to end, generating enough variation to avoid simple deny lists while keeping the payload consistent across the whole set.
Analysts also point to AI-assisted authoring of the surrounding package content, a growing pattern called AI-slopped packages. Fake names, fabricated descriptions, and generated readmes make malicious dependency trees look legitimate at a glance. Lowering the cost of entry for a campaign is exactly why the supply chain, not unknown infra changes, is now the perimeter attackers prefer.
This is not an isolated event. A wave of similar npm findings earlier in 2026 targeted cloud and CI/CD secrets through typosquatting and dependency confusion. The pattern is identical: poison the registry, get into a build, steal a token, and move inward. A freelancer small team is a much softer target than a hardened enterprise with a dedicated security team.
What to do next
- Pin your dependencies and check the lock file into source. Never rely on loose caret range resolution in production builds, and make installs reproducible.
- Add registry auditing tooling to your CI, so the open-source security tools and compute dependency diffrences are auto-scanned on every pull request.
- Look at every new or unexpected dependency that appears in a review; an install over a typo (e.g. lodasxh) is one bad keystroke away from a silent trojan.
- Rotate CI/CD credentials and you use short-lived tokens for your build agents so stolen secrets expire before they are useful.
- If you have GitHub Actions, add environment restrictions and pre-inspect any dependency, not just obviously named ones.
- Watch the npm advisory database and your audit output regularly; a new flood can start and be removed within days.
The bigger picture
Supply chains are the new front lines, and the fix is not to stop using packages but to make the change safely. I build infrastructure that ships reliably, and reliable shipping includes knowing exactly what reaches a build image. For me, that means lock down the registry, gate new dependencies in the pipeline, and treat every lock file as production service. When code can reach your servers in milliseconds, the packages in the tree are part of that supply. A team that bakes dependency governance into CI/CD builds both faster and safer than the one hoping nothing breaks.