NUL1DROPPER is a cross-platform downloader hidden in hundreds of malicious npm packages published in early August 2026. The most important exposure detail is that installing one of the packages is not, by itself, proof that the native payload ran. In the verified example, execution starts when application, test, build, or production code imports the module.
That distinction also explains why npm install --ignore-scripts is not a complete defense here. The analyzed package has no preinstall or postinstall hook; its initialization code runs through a normal require(). Developers and CI teams should therefore check both dependency records and actual imports before deciding how far recovery must go.
Are you affected by NUL1DROPPER?
| What you found | What it means and what to do |
|---|---|
| A package name appears only in a search result, advisory, or cache that was never used | No execution evidence. Block the package, review how it entered the workflow, and keep monitoring. |
A listed package is in package.json or a lockfile, but no source, test, build, or runtime path imports it |
Dependency exposure is confirmed, but native-payload execution is not. Remove it, preserve the lockfile and install/build logs, and verify that no transitive code loaded the module. |
| Application, test, build, or production code imported the package | Treat the host or CI runner as potentially compromised. Isolate it, preserve process and network evidence, and scope every secret accessible to that environment. |
| Dropped files, matching process ancestry, DNS activity, or platform persistence are present | Execution evidence is strong. Rebuild affected systems from trusted media and rotate exposed credentials from a clean device after containment. |
OpenSourceMalware verified checkout-mobile-bnpl version 35.6.9 as one example. It is not a complete list of the campaign’s packages. Use the researcher’s maintained package list to compare names and versions rather than assuming every similarly named module is malicious.
NUL1DROPPER, WEL1DROPPER, and Flooding Dropper
The primary analysis names the JavaScript downloader NUL1DROPPER. Some secondary reporting uses WEL1DROPPER, derived from the fallback domain, or Flooding Dropper. This article uses NUL1DROPPER because it is the name in the technical report, while noting the aliases so defenders can correlate alerts and search results.
The report’s “Russian” attribution is based on circumstantial clues, not proof of operator identity. Those clues should not be turned into a firm attribution claim.
How the npm package becomes a downloader
- A developer adds or inherits a malicious dependency. The campaign used randomly generated names and names that resemble plausible AI-suggested packages. For the broader risk model, see our guide to slopsquatting in AI-assisted development.
- Code imports the module. In the verified sample,
index.jsloads a helper that immediately starts the downloader. There is no install-script gate to block. - The downloader profiles the platform. It selects a Windows, Linux, or macOS path and attempts to retrieve a native payload from attacker-controlled infrastructure.
- A DNS TXT fallback can reconstruct the payload. If the primary web hosts fail, the code can recover encoded chunks from TXT records under
wel1[.]ru. We are intentionally not reproducing the payload URLs or reconstruction procedure. - The native stage runs separately. The npm JavaScript is a downloader. Credential theft, persistence, remote access, and other later behavior belong to the separately analyzed platform payloads, not to the first-stage script alone.
This is different from the recent Keyv/ChainDrop npm worm, which propagated through compromised maintainer accounts. NUL1DROPPER’s practical lane is import-time execution from a large pool of deceptive packages.
Artifacts worth checking
| Platform or evidence source | Observed clue |
|---|---|
| Dependency and source history | Package names from the maintained campaign list; recent package.json or lockfile changes; direct or transitive imports in source, tests, build scripts, serverless bundles, or production code. |
| Windows | A file matching %TEMP%\dotnet_diag_{8 hex characters}.exe, launched through a detached cmd.exe chain, plus an analytics_state marker in the temporary directory. |
| Linux | A hidden executable matching /var/tmp/.cache_{8 hex characters}, launched through /bin/sh, plus /tmp/.analytics_state. |
| macOS | The same first-stage downloader logic, followed in the analyzed native payload by files under ~/.local/share/runtime and a LaunchAgent named com.apple.windowserver.helper.plist. |
| Network and DNS | Node.js process ancestry followed by requests to unfamiliar Workers hosts, or DNS TXT queries under wel1[.]ru. Treat the domain as an indicator to investigate, not as a payload-retrieval instruction. |
| Timing marker | analytics_state stores a timestamp used to suppress another run for roughly six hours. Its absence does not prove the host is clean. |
How to investigate developer and CI exposure
- Preserve the current state. Save the lockfile, dependency tree, build logs, CI job metadata, container or VM identity, DNS logs, proxy history, and endpoint process tree before cleanup changes timestamps or removes evidence.
- Search for both direct and transitive use. A malicious package may have been introduced by generated code, a test helper, a copied snippet, or another dependency. Search source and generated bundles for the module name and follow the import path.
- Decide whether import occurred. An install record without an import is a different incident from a Node.js process loading the module. Review test, build, serverless, desktop-app, and production startup paths, not only local developer commands.
- Correlate host and network evidence. Match Node.js ancestry with the temporary file patterns, shell or
cmd.exelaunches, unfamiliar outbound requests, and DNS TXT lookups. One isolated indicator may have a benign explanation; a connected chain is much stronger evidence. - Scope inherited credentials. List repository, npm, CI/CD, cloud, SSH, signing, package-registry, browser-session, wallet, and deployment secrets that the process or runner could access.
If AI-generated package names are part of the root cause, our TrapDoor analysis explains another way developer tooling can redirect agents toward attacker-controlled dependencies. Keep the incidents separate during triage; shared “AI supply chain” wording does not make their artifacts interchangeable.
If the package was imported: contain and recover
- Isolate the workstation or runner. Do not use the suspected host to rotate secrets or sign new releases.
- Revoke active sessions first when ongoing access is possible. Then rotate repository, npm, cloud, CI/CD, SSH, signing, deployment, browser, and wallet credentials from a known-clean device. Our API-token recovery guide explains why cost controls and rotation both matter.
- Invalidate affected builds and artifacts. Identify releases, containers, caches, and packages produced after the first suspicious import. Rebuild them from reviewed source and trusted dependencies.
- Rebuild confirmed-compromised systems. Removing the npm package does not remove a native payload that already executed. For developer laptops and reusable CI workers, a clean rebuild is safer than relying on deletion alone.
- Hunt downstream. Review account activity, package publications, repository changes, cloud actions, new keys, deployment history, and persistence on systems reached with the exposed credentials.
On an isolated Windows workstation, after preserving evidence, a full Gridinsoft Anti-Malware scan can help find dropped files, suspicious startup entries, scheduled tasks, services, and related persistence. A clean scan cannot restore stolen credentials or prove that no account was exposed, so it should support—not replace—the rebuild and credential-recovery plan.
If the process path is wrong, the name imitates a Windows component, or high CPU started after an unknown installer, scan for hidden miners, services, startup entries, and bundled components.
Scan the isolated Windows PCFAQ
Does finding a listed package in a lockfile prove NUL1DROPPER ran?
No. It proves dependency exposure. The documented trigger occurs when code imports the module, so investigate source paths, build/test execution, process ancestry, network activity, and dropped artifacts before declaring native-payload execution.
Does --ignore-scripts block this campaign?
It blocks npm lifecycle scripts, but the verified NUL1DROPPER example executes through normal module initialization during require(). That is why import analysis is essential.
Is deleting the npm package enough?
Only if you establish that the module was never imported and no native payload ran. When execution evidence exists, isolate and rebuild the system, invalidate affected artifacts, and recover accessible accounts and secrets from a clean device.
References
- Paul McCarty (6mile). “Russian AI Slopsquatting Publishes 700+ Malicious NPM Packages.” OpenSourceMalware, published August 6, 2026; accessed August 8, 2026. Primary technical report.
- OpenSourceMalware. “WEL1DROPPER Package List.” GitHub, living campaign list; accessed August 8, 2026. Maintained package list.
