What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In an August 2026 disclosure, Sonatype reported 846 npm components linked to the Flooding Dropper campaign, which delivered platform-specific malware through packages published by many accounts. That scale showed how malicious publishing can strain registry moderation. It does not establish that the campaign was still publishing or that its packages remained available on October 8, 2026; the public reporting cited here does not verify their current registry status.
What was Flooding Dropper?
Flooding Dropper was the name used for an August 2026 npm malware campaign. On August 5, Sonatype Research Labs said it had identified 846 implicated software components, tracking the activity as sonatype-2026-005660. That is a count from Sonatype’s initial disclosure, not a current total of malicious npm packages or a verified count of packages still present in the registry.
Sonatype’s account began with a report from OpenSourceMalware about the package bigops-backend. The packages were published through many newly created accounts, with each account reportedly publishing only a few packages. Names included terms such as “bigops” and “bnpl,” while slight code variations could make exact-signature matching less reliable. Those patterns can help investigators search for related activity, but they are not durable proof that a package is malicious—or a complete way to find every related package.
How did the packages deliver malware?
Sonatype described first-stage JavaScript that checked the operating system and processor architecture, selected a compatible payload, tried to retrieve it remotely, wrote it to a temporary directory, and launched it as a detached process. If direct HTTPS retrieval failed, the code could use DNS TXT records as a fallback. The analysis described platform-specific payload delivery for Windows, Linux, and macOS.
#1 Best Overall
The trigger was not necessarily the familiar automatic install-hook path. The Cloud Security Alliance described campaign samples whose README instructions told users to load code manually with require(), rather than relying on preinstall or postinstall hooks commonly monitored by scanners. That is an observed technique, not evidence that every package used the same trigger.
Sonatype’s initial Windows analysis also reported anti-analysis and persistence behavior: interference with ETW and AMSI monitoring, sandbox checks, persistence under AppData, a Registry Run key and a scheduled task, and retrieval of an encrypted follow-on payload. These details describe Sonatype’s analysis, not a guarantee that every package or platform had identical capabilities.
How did npm malware put developer tokens at risk?
The risk begins when a developer executes untrusted package code. In this campaign, the reported chain used package code to launch a separate payload; the campaign has been described as a token-stealing threat. The cited public analyses describe delivery and execution behavior, but do not establish an exhaustive list of credentials or token locations collected by every sample. It would therefore be misleading to claim that all packages stole the same tokens in the same way.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →For defenders, the key point is that reviewing only automatic install hooks may miss code that a user imports or runs manually. Package review should consider the README’s instructions and the code paths reached by normal use, as well as install scripts. A package’s presence in the registry—or a clean result from one scanner—is not, on its own, a safety guarantee.
Rank #3
Were the package names AI-generated “slopsquatting”?
Some early descriptions called the naming pattern “AI slop squatting” or possibly randomly generated typo-squatting. The Cloud Security Alliance said the origin of these specific names was unconfirmed. An attacker could generate plausible package names without using AI-hallucinated suggestions, so the campaign should not be presented as proven evidence that AI-generated names were registered.
What protections had npm and GitHub announced?
By July 2026, npm and GitHub had announced controls at several points in the supply-chain attack path. Their presence matters, but rollout, configuration, and compatibility vary. GitHub’s July 28 update put the limitation plainly: “Supply chain attacks chain together several weaknesses, and there is no single security capability that can stop them.”
| Attack-chain stage | Announced measure | What it can—and cannot—do |
|---|---|---|
| Account access | GitHub described a 72-hour read-only period for certain high-impact accounts after an email change or use of a two-factor authentication recovery code. (GitHub, July 2026.) | Slows some risky account changes; it is not a block on every compromised publisher account. |
| Publishing | GitHub’s update described CircleCI support for npm trusted publishing and staged publishing that requires further approval and 2FA. (GitHub, July 2026.) | Can strengthen publishing workflows when supported and configured; the announcement does not mean every account or workflow was already using these measures. |
| Workflow execution | GitHub described safer Actions defaults and restrictions on untrusted workflow triggers and cache writes. (GitHub, July 2026.) | Reduces exposure to certain workflow risks; it does not inspect every package for malicious behavior. |
| Dependency updates | GitHub said Dependabot version-update pull requests would have a default three-day cooldown. (GitHub, July 2026.) | Introduces time for scrutiny before some updates; it is a delay, not a verdict that an update is safe. |
| Install-time execution | GitHub described npm v12’s planned rollout of install scripts disabled by default, with an option to approve specific scripts. (GitHub, July 2026.) | Can reduce automatic execution exposure, but install scripts have legitimate uses and approval may be needed for packages a project relies on. The update described a planned rollout, not universal availability. |
These controls address different weaknesses. Account safeguards and publishing controls aim to make unauthorized releases harder; workflow defaults and install-script choices reduce some execution paths; cooldowns create time for review. None alone detects every malicious package, and controls described as planned or conditional should not be assumed to be active for every user.
How can you check whether an npm package is safe?
No single check can certify a package as safe. Use several checks in proportion to the package’s access and importance:
Best Value
- Confirm the package name and publisher through a trusted project source, and inspect whether the package’s purpose, repository, release history, and ownership changes make sense.
- Read the README and inspect the code paths the package asks you to run, including manual imports as well as install scripts. Treat instructions to load unexplained code as a warning sign.
- Review dependency changes before merging them. A cooldown or scanner can help, but neither replaces understanding what changed.
- Use npm’s documented guidance on two-factor authentication, including security keys or authenticator apps, for accounts that can publish packages.
- For organizations, consider controls on publishing, dependency updates, and package execution together. Account for compatibility before blocking install scripts that a legitimate dependency requires.
These checks lower risk; they cannot prove that a package is harmless. A package can change after review, and subtle code variations may evade exact-match detection.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How do you report a malicious npm package?
npm’s malware-reporting documentation asks reporters to identify the package, all affected versions, and concrete details or evidence. npm says its Security team validates reports and describes actions that can include removing packages, publishing security placeholders, and issuing advisories. That documented process does not establish that every package reported in this campaign was removed or when any removal occurred.
What should you do if you may have installed a campaign package?
Sonatype advises treating affected hosts as compromised, isolating them, checking for persistence and relevant telemetry, and rebuilding where appropriate. It also recommends checking lockfiles, caches, container layers, and internal mirrors. After remediation, rotate credentials that may have been exposed; rotating them before removing the malware could allow an active payload to capture the replacements. These are response recommendations, not a guarantee that any one cleanup process finds every trace.
Free tools Windows power users keep installed
One-click scans. No signup required.
Is Flooding Dropper still active?
The cited reporting establishes a large campaign disclosed in August 2026 and platform measures announced by July. It does not establish whether new Flooding Dropper packages were still being published, whether all implicated packages had been removed, or the campaign’s total reach as of October 8, 2026. The defensible conclusion is narrower: the incident demonstrated a substantial malicious-publishing problem, while public evidence here is insufficient to say that this particular campaign remains active—or that the broader problem is under control.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
