test-dev npm Packages Flagged as Critical Malware

On August 1, 2026, our catalog logged a coordinated set of eight malicious npm packages that all share one naming pattern: the test-dev- prefix. The eight test-dev npm packages are test-dev-boot, test-dev-link, test-dev-exec, test-dev-sync, test-dev-host, test-dev-watch, test-dev-store, and test-dev-dispatch. Every one of them was classified as critical malware on the same day. That is the signature of a single operator publishing a family of packages in one push, not a scatter of unrelated typos. If any of these names reached a build, a developer laptop, or a CI runner in your organization, treat that machine as compromised until you can prove otherwise.

What happened

Eight npm packages built around the test-dev- prefix were added to our catalog as critical malware on 2026-08-01. Each entry documents malicious code in a separate package:

These packages did not arrive alone. The same day, our catalog also flagged other malicious npm packages such as @moxfive-llc/common and pp-react-worldready, plus a batch of malicious PyPI packages including asdk-plugin-alphagen. August 1 was a heavy day for registry malware across both ecosystems.

We want to be precise about what is confirmed and what is not. The package names, the critical classification, and the publish date are the hard facts. Detailed public write-ups of the exact payload inside each test-dev package were thin at the time we catalogued them, and we have not seen a vendor report that names a single threat actor or lists indicators of compromise for this specific family. So this article documents what the catalog records and explains the risk model, rather than asserting a payload we have not independently confirmed.

Why the test-dev npm packages stand out

The test-dev- prefix is the interesting part. Real projects rarely publish generic public packages named test-dev-boot or test-dev-exec. Names like these usually mean one of two things.

The first possibility is dependency confusion. Many teams keep internal helper packages with plain, functional names (test-dev-sync, test-dev-store, test-dev-dispatch) inside a private registry. If an attacker publishes public packages with the exact same names and a higher version number, a misconfigured installer can pull the public malicious copy instead of the private one. We covered that exact pattern in the npm and PyPI dependency confusion wave the day before, and the test-dev family fits the same playbook.

The second possibility is opportunistic bait. Developers who search npm for a quick scaffolding or test harness might install something that looks disposable and low risk. A name with "test" and "dev" in it reads as harmless. That perception is the point.

Either way, the effect is the same. Code from an untrusted publisher runs on a machine that holds credentials.

Who is affected by the test-dev npm packages

Anyone who installed one of the eight test-dev npm packages, directly or as a transitive dependency, is in scope. Three groups carry the most risk.

CI and build systems are first. A runner that installs dependencies fresh on every job often holds cloud keys, registry tokens, and signing material in environment variables. Malicious install code runs with all of it in reach.

Developer workstations are second. A laptop typically has an SSH key, a .npmrc with a publish token, cloud CLI credentials, browser session data, and sometimes a crypto wallet. This is the same target set that credential-stealing npm malware has gone after all year. CyberPress reported a separate npm stealer named Joyfill days earlier that targeted GitHub tokens, browser passwords, and crypto wallets, and Microsoft documented typosquatted npm packages built to steal cloud and CI/CD secrets earlier in 2026. The test-dev family lands in the middle of that trend.

Internal platform teams are third. If your organization uses private packages with generic names, dependency confusion means the blast radius can extend past the person who ran the install into whatever that build had access to.

How this class of npm malware works

We have not confirmed the exact behavior of each test-dev package, so read this as the standard mechanics for critical npm malware, not a line-by-line description of these eight.

Malicious npm packages usually run in one of two windows. The first is install time. A preinstall or postinstall script in package.json executes automatically when you run npm install, before you ever import the code. The second is runtime, when your application calls require() or import on the package and top-level code fires.

Once code runs, the common goals are collection and exfiltration. The malware reads environment variables, files like ~/.npmrc, ~/.aws/credentials, and ~/.ssh/id_rsa, and sometimes browser storage. It packages what it finds and sends it to an attacker-controlled endpoint. Many samples also pull a second stage from a remote host, which lets the operator change the payload after the package passes a first look. None of this needs a vulnerability in your code. Installing the package is the exploit.

How to check if you are affected

Start with your lockfiles and your node_modules. Run these from the root of each repository.

grep -E "test-dev-(boot|link|exec|sync|host|watch|store|dispatch)" \
  package-lock.json yarn.lock pnpm-lock.yaml npm-shrinkwrap.json 2>/dev/null

Ask npm directly whether any are present in the resolved tree:

npm ls test-dev-boot test-dev-link test-dev-exec test-dev-sync \
  test-dev-host test-dev-watch test-dev-store test-dev-dispatch

Look for the folders on disk, including nested copies pulled in as transitive dependencies:

find . -type d -path "*/node_modules/test-dev-*"

Check your CI history too. Search build logs for the package names and for any npm install or npm ci step that ran between the publish date and the moment you pinned or purged your dependencies. If a runner installed one of these, the secrets that runner could see should be considered exposed.

Remediation

If you find any of the eight packages, work in this order.

First, remove the package and rebuild your tree from a clean state.

npm uninstall test-dev-boot   # repeat for each name you found
rm -rf node_modules
npm ci --ignore-scripts

Second, rotate every secret the affected machine could reach. Do not skip this because the cleanup looked easy. Rotate npm publish tokens, GitHub personal access tokens and Actions secrets, cloud provider keys, and any SSH keys stored on the host. If a browser profile or a crypto wallet was present on a developer laptop that ran the install, treat those credentials and wallet seeds as burned and move funds if a wallet was involved.

Third, harden the install path so the next family cannot run code the same way.

npm config set ignore-scripts true

Disabling install scripts breaks a small number of legitimate packages, so test before you roll it out widely, but it removes the most common automatic execution window. Pair it with npm ci against a reviewed lockfile in CI so builds are reproducible and cannot silently pull a new version.

Fourth, close the dependency confusion gap if you use private packages. Scope your internal packages under an npm org, pin your private registry for that scope in .npmrc, and configure your installer so a public package can never shadow a private name. If you can, block newly published or very low-download packages at a proxy such as a private registry or an allowlist.

Finally, report and remove. If you still see any of these packages live on npm, report them so the registry can pull them, and remove them from any internal mirror or cache you run.

FAQ

Are the test-dev npm packages safe to use?

No. All eight (test-dev-boot, test-dev-link, test-dev-exec, test-dev-sync, test-dev-host, test-dev-watch, test-dev-store, test-dev-dispatch) are classified as critical malware in our catalog as of August 1, 2026. There is no legitimate reason to keep them installed. Remove them and rotate any secrets that were reachable during the install.

How do I know if I am affected by the test-dev npm malware?

Grep your lockfiles for the test-dev- names, run npm ls against the full list, and search your node_modules folders and CI build logs. If any name shows up, assume the host that installed it exposed its environment variables and credential files, and start rotating secrets from there.

What should I rotate if I ran one of these packages?

Rotate npm tokens, GitHub tokens and Actions secrets, cloud access keys, and SSH keys on any affected host. On a developer laptop, also reset browser-stored passwords and session cookies, and if a crypto wallet was present, move funds to a new wallet with a fresh seed. Rotation is the step people skip and the one that actually contains the damage.

Is this the same as the August 1 internal package names wave?

They were catalogued in the same window and share the dependency confusion pattern, so they may well be part of one broad operation. We are documenting the test-dev family on its own because it is a distinct, self-contained cluster with a single naming scheme. If a vendor later ties it to the wider wave or names a threat actor, we will update the entries.