npm and PyPI Malware Wave Hits Internal Package Names

On 2026-08-01 our catalog added more than two dozen malicious packages across npm and PyPI in a single day. Most of them share one trait: the names copy the private, internal libraries that real companies use inside their own builds. That is the signature of a dependency confusion attack. Twenty-two of the packages are on npm and three are on PyPI, and every npm entry is rated critical. This is one of the larger single-day batches we have logged, and it lines up with a pattern we tracked through July around npm dependency confusion against internal package names.

The specific package names and the date they were flagged come from our own detection feeds. Per-package payload analysis is still limited at the time of writing, so this article separates what we can confirm (the names, the ecosystems, the timing) from how this class of attack is documented to work.

What happened

On 2026-08-01 a wave of malicious packages was flagged across two registries. They fall into four groups.

Group one is a set of scoped npm names that read like private frontend and platform libraries: @moxfive-llc/common, @sof-assistant-fe-lib/vertical-faqs, @spending-behavior-ui/widget-insights, @spending-behavior-ui/cashflow-widget, @finance-ui/snackbar-ifpe, @mplay-core-lib/utilities, @one-chat/react, and @nordic-dev/linting-tools.

Group two is unscoped npm names that look like internal application modules: portway, polylabel-web-lib, sso-users-detection, notifications-broadcast, frontend-regulations, and process-status-widget.

Group three is a tight npm cluster published under one prefix with action-word suffixes: test-dev-boot, test-dev-sync, test-dev-host, test-dev-watch, test-dev-store, test-dev-dispatch, test-dev-link, and test-dev-exec.

Group four is on PyPI: three plugins that impersonate an internal SDK called "asdk", namely asdk-plugin-alphagen, asdk-plugin-ai-platform, and asdk-plugin-legacy.

Read together, the naming is the story. Scopes like @finance-ui, @spending-behavior-ui, @sof-assistant-fe-lib, and @mplay-core-lib are not products you would install from the public registry. They are the kind of names a single company uses for its own private packages. Publishing those exact names to the public npm and PyPI registries is the whole mechanism of a dependency confusion attack.

Why the names matter

Dependency confusion works because many package managers, by default, will pull a package from the public registry if a matching name exists there and the version number is higher than the private one. An attacker who learns your internal package names, from a leaked package.json, a public build log, or a source map, can register those names publicly and wait for a misconfigured install to reach out to the wrong registry.

This is not theoretical. Microsoft's security team documented a batch of npm packages that abused dependency confusion to profile developer machines, running reconnaissance through install hooks and sending the results back to the attacker. Sonatype separately analyzed a 176-package npm campaign built specifically to shadow companies' internal dependency names. SafeDep tracked a similar run that targeted a single organization's private packages. The 2026-08-01 batch fits that same shape: many names, several organizations, one delivery method.

The test-dev cluster

The test-dev-* group is the odd one out. Names like test-dev-exec, test-dev-dispatch, and test-dev-sync do not obviously map to a specific company's internal library. A common explanation for tightly numbered or themed clusters like this is automated publishing, where an actor pushes many small packages to test exfiltration infrastructure, measure install telemetry, or seed bait for typo and confusion hits. We flag the whole cluster as critical, but the intent behind the naming is not confirmed. Treat any test-dev-* dependency in your tree as suspect until you can prove where it came from.

Who is affected

The people at direct risk are developers and CI systems at organizations whose private package names collide with any name in this wave. If your company owns a @finance-ui scope, a @spending-behavior-ui scope, or internal packages called sso-users-detection or notifications-broadcast, a build that is not locked to your private registry could have resolved the public, malicious version instead.

The second group at risk is anyone who installed a package by mistake, through a typo or a copied command, and pulled one of these names without realizing it was not the intended dependency. Because several of the names read like plausible utility libraries, that mistake is easy to make.

How this class of attack works

Once a malicious package lands in a build, the usual first move is code that runs at install time. On npm that is a lifecycle script such as preinstall or postinstall; on PyPI it is code in setup.py or a build hook. That code runs with the developer's or CI runner's privileges before any application code is reviewed.

From there, campaigns like the ones Microsoft and Sonatype documented collect host and network details, environment variables, and tokens, then send them to an attacker-controlled endpoint. Some stop at reconnaissance. Others pull a second-stage payload. We do not have a confirmed second-stage sample tied to every package in this specific wave, so treat the exfiltration-and-recon model as the baseline threat and assume secrets exposed to the affected build are burned.

Two ecosystem changes reduce this exposure but do not remove it. npm's newer releases block install scripts by default, which cuts off the most common execution path for packages that rely on postinstall. GitHub has also added publish-time malware scanning for npm, which raises the odds that an obviously malicious upload is caught quickly. Neither control helps if your resolver still prefers the public registry over your private one, so the configuration fix below still matters.

How to check if you are affected

First, search your installed tree and lockfiles for any of the names above.

# npm / pnpm / yarn projects
npm ls @moxfive-llc/common @one-chat/react @finance-ui/snackbar-ifpe 2>/dev/null
grep -rE "test-dev-(boot|sync|host|watch|store|dispatch|link|exec)" package-lock.json pnpm-lock.yaml yarn.lock
grep -rE "@spending-behavior-ui|@sof-assistant-fe-lib|@mplay-core-lib|@nordic-dev|polylabel-web-lib|sso-users-detection|notifications-broadcast|frontend-regulations|process-status-widget|portway" package-lock.json pnpm-lock.yaml yarn.lock

For Python projects, check installed distributions and any resolved requirements.

pip list 2>/dev/null | grep -E "asdk-plugin-(alphagen|ai-platform|legacy)"
grep -rE "asdk-plugin-(alphagen|ai-platform|legacy)" requirements*.txt poetry.lock Pipfile.lock 2>/dev/null

If any of these return a hit, look at where the package resolved from. A public-registry URL for a name you believe is internal is the confirmation that a confusion attack landed.

Remediation

If you find one of these packages, remove it and stop the affected build from running further install scripts.

npm uninstall <package>        # or pnpm remove / yarn remove
npm cache clean --force
# reinstall with scripts disabled while you audit
npm ci --ignore-scripts

Then close the gap that let a public package win over your private one. Pin every private scope to your internal registry so a public name of the same scope cannot be resolved.

# .npmrc, example for a private scope
@finance-ui:registry=https://registry.internal.example.com/
@spending-behavior-ui:registry=https://registry.internal.example.com/
//registry.internal.example.com/:_authToken=${NPM_TOKEN}

For Python, install only from your controlled index and avoid mixing public and private indexes without an explicit allowlist. Use --index-url for your private index rather than --extra-index-url, which can silently prefer a public match.

Finally, rotate any credential that was present in an affected build: registry tokens, cloud keys, and CI secrets. Assume anything readable from the environment at install time is compromised, and review CI logs for outbound connections to unfamiliar hosts around the install step.

FAQ

Is dependency confusion still a real threat in 2026

Yes. This 2026-08-01 wave is a live example, and it follows documented 2026 campaigns from Microsoft and Sonatype that used the same technique. The defense is configuration, not luck: lock every private scope to your internal registry and do not let a public name outrank it.

How do I know if I installed one of these packages

Search your lockfiles and installed packages for the names listed above, then check the resolved source URL for each hit. If an internal-looking name resolved from the public npm or PyPI registry, you were exposed and should rotate any secrets that build could read.

What is the test-dev npm cluster

It is a group of eight npm packages published under the test-dev- prefix (boot, sync, host, watch, store, dispatch, link, exec) that our catalog flagged as malware on 2026-08-01. Unlike the scoped names in the same wave, these do not clearly map to one company, and their exact purpose is not confirmed. Treat any test-dev-* dependency as untrusted.

Do npm install-script blocking and GitHub scanning make me safe

They help but do not close the hole. Blocking install scripts removes the most common execution path, and publish-time scanning catches some malicious uploads early. Neither changes how your resolver picks a registry, so a build that still prefers public over private packages remains exposed until you fix the registry configuration.