DependencyWatch.io
FeedSolutionsSubmitScan your lockfile
Feed
CriticalPublished 1 Aug 2026Updated 2 Aug 202610 packages · 10 versions

GitHub Advisory npm CWE-506 sweep - 10-package 2026-08-01 batch (`test-dev-*` 8-package sequential-namespace burst, `@moxfive-llc/common` scoped RAT, `pp-react-worldready` OpenSSF-PA C2 domain communicator)

Summary

GHSA published 10 npm CWE-506 advisories dated 2026-08-01 - an 8-package test-dev-* sequential-namespace burst (test-dev-boot, -host, -watch, -sync, -dispatch, -exec, -store, -link), a @moxfive-llc/common scoped RAT publish, and pp-react-worldready@1.0.0 flagged by OpenSSF Package Analysis for communicating with a domain associated with malicious activity.

dependency-confusionci-cd-compromisecredential-theftinfostealer
Detected by
GitHub Advisory Database · OpenSSF Package Analysis · npm Security
Also known as
2026-08-01 GHSA npm batch · test-dev-* burst · @moxfive-llc scoped RAT · pp-react-worldready C2 communicator
Ecosystems
npm
Packages tracked
10

What happened

On 2026-08-01, the GitHub Advisory Database published 10 new npm CWE-506 (Embedded Malicious Code) advisories in a same-day burst. This module catalogues that batch. Small batch relative to the massive 2026-07-31 wave (91 packages) - the 08-01 batch reads as a tail-end of the same operator activity plus one distinct scoped RAT and one OpenSSF-PA C2-domain communicator.

Cluster A - test-dev-* sequential-namespace burst (8 packages, all 2026-08-01)

| Package | Notes | |---|---| | test-dev-boot | test-dev-<verb> template | | test-dev-host | test-dev-<verb> template | | test-dev-watch | test-dev-<verb> template | | test-dev-sync | test-dev-<verb> template | | test-dev-dispatch | test-dev-<verb> template | | test-dev-exec | test-dev-<verb> template | | test-dev-store | test-dev-<verb> template | | test-dev-link | test-dev-<verb> template |

Same-day publish of 8 packages under a shared test-dev-<verb> naming template. Every advisory in the cluster carries the standard CWE-506 boilerplate ("any computer that has this package installed or running should be considered fully compromised") with no additional per-package behaviour prose. The naming pattern reads strongly as researcher / red-team upload activity - no ordinary developer types npm install test-dev-boot - but GHSA classified all 8 as CWE-506 embedded malicious code, meaning static analysis or Package Analysis (OpenSSF) tripped on real malicious behaviour in the tarballs regardless of the researcher-vs-criminal origin.

A lockfile hit on any test-dev-* name is still an incident: either genuine malware or an unauthorised researcher upload that still exfiltrates on install (researcher uploads that ship real payloads are treated as CWE-506 by GHSA precisely because the impact on unlucky downloaders is identical).

Cluster B - @moxfive-llc/common scoped RAT (1 package, 2026-08-01)

| Package | Notes | |---|---| | @moxfive-llc/common | scoped RAT - plausibly targeted at MoxFive Inc customers/partners |

Attacker-controlled @moxfive-llc scope with a generic common sub-name. MoxFive Inc is a real US cybersecurity incident-response firm - a plausible target for a scoped dep-confusion or brand-impersonation probe against MoxFive customers who might install @moxfive-llc/* tooling from a build script. The common sub-name is a canonical internal-utility package name shape used across many engineering orgs, maximising the chance of a lockfile collision at any target that maintains an internal @moxfive-*/common package for tooling.

Cluster C - pp-react-worldready OpenSSF-PA C2-domain communicator (1 package, 2026-08-01)

| Package | Version | Notes | |---|---|---| | pp-react-worldready | 1.0.0 | OpenSSF PA: "communicates with a domain associated with malicious activity" |

Single-version drop under a pp-* name shape (pp- prefix seen in many payments-adjacent internal React library namespaces). The worldready sub-name pattern matches PayPal-internal terminology for i18n / world-ready localisation React components - the name looks purpose-built to catch a developer at a payments-adjacent org looking for an internal pp-react-* localisation library. Advisory ID GHSA-4g95-5h46-4643.

Unlike Cluster A and B which carry the generic CWE-506 "fully compromised, rotate secrets" boilerplate, this advisory's "Details" prose is the OpenSSF Package Analysis autotriage flag - "the package communicates with a domain associated with malicious activity" - indicating active outbound C2 traffic was observed at analysis time, not merely static-metadata heuristics. Any host that installed pp-react-worldready@1.0.0 should be treated as having phoned out to a known-malicious domain during install or import.

Registry state

All 10 packages security-replaced during the 2026-08-01 batch. Original version tarballs are no longer resolvable on the public registry, but private mirrors (Verdaccio, Artifactory, Nexus) that cached tarballs BEFORE the takedown WILL keep serving the original versions.

Related tracked activity

  • Cluster A test-dev-* naming shape echoes the earlier asdsafsadad/asdsafsafdasdsaasdasda researcher/junk-name uploads catalogued in npm-2026-07-31-ghsa-malware-sweep Cluster D. Same operator profile (test-shape names published in bursts, GHSA-flagged CWE-506, no per-package behaviour prose).
  • Cluster B @moxfive-llc scoped RAT fits the same enterprise / vendor-scope brand-impersonation pattern catalogued in npm-2026-07-31-ghsa-malware-sweep Cluster G (@finance-ui, @spending-behavior-ui, @meli-testing, @cr-invested-ui-components - enterprise-scope dep-confusion sweep).
  • Cluster C pp-react-worldready@1.0.0 is a single-package OpenSSF-PA-flagged C2-domain communicator - same signature (active outbound network traffic caught by OpenSSF PA) as the OpenSSF-PA cluster in npm-2026-07-29-ghsa-malware-sweep Cluster F (num-format-helper, string-format-kit, date-sanitize-helper, etc).
  • No threatActor field is set - GHSA advisories in this batch use only the CWE-506 boilerplate with no named actor attribution.

Affected packages (10)

These are usually pulled in as transitive dependencies rather than installed directly. Check your whole tree at once - it runs in your browser and nothing is uploaded.

Check package-lock.json

Impact

  • Any host that installed any of the 9 npm packages listed below should be treated as fully compromised - every GHSA advisory in this batch uses the CWE-506 boilerplate: "any computer that has this package installed or running should be considered fully compromised - rotate all secrets from a different computer" - and no patched version exists
  • *Cluster A - `test-dev- 8-package sequential-namespace burst** (8 packages, all >= 0, all 2026-08-01): test-dev-boot, test-dev-host, test-dev-watch, test-dev-sync, test-dev-dispatch, test-dev-exec, test-dev-store, test-dev-link. Same-day publish of 8 packages under a shared naming template (test-dev-<verb>) - one operator running a namespace-enumeration exercise or dev-tooling name-shape probe. The test-dev- name shape reads as researcher / red-team test uploads (developer would not typically install a package literally named test-dev-`), but GHSA classifies all 8 as CWE-506 embedded malicious code so treat lockfile hits as real incidents
  • Cluster B - @moxfive-llc/common scoped RAT (1 package, >= 0, 2026-08-01): @moxfive-llc/common. Attacker-controlled @moxfive-llc scope with a generic common name shape - plausibly a targeted publish against an org named "MoxFive LLC" (MoxFive Inc is a real US cybersecurity IR firm) to catch developers looking for their tooling. The common sub-name is a canonical internal-utility package name shape used at most engineering orgs
  • Cluster C - pp-react-worldready OpenSSF-PA C2-domain communicator (1 package, = 1.0.0, 2026-08-01): pp-react-worldready. GHSA-4g95-5h46-4643 records OpenSSF Package Analysis flagged the tarball because "the package communicates with a domain associated with malicious activity." Single-version drop under the pp-* name shape (pp prefix often used by internal payment / PayPal-adjacent React libraries) - plausibly a targeted dep-confusion / brand-impersonation probe against an internal pp-* React component namespace at a payments-adjacent org that maintains a worldready-shaped i18n / localisation module
  • None of the 10 packages retain original tarballs on the public npm registry - all replaced with security sentinels during takedown. Private registry mirrors (Verdaccio, Artifactory, Nexus) that cached tarballs BEFORE the takedown WILL keep serving the original versions

What to do

  1. 1Grep every lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) for each name in the packages map below. Any match is a supply-chain incident: rotate every credential the build runner could reach and re-image the build host
  2. 2*Cluster A (`test-dev-)**: any lockfile hit on any of the 8 test-dev- packages is either a researcher/red-team unauthorised upload landing on your CI or an actual malicious drop - both require the same response. Delete the resolved package, purge from any private-registry cache, and rotate the credentials that the build had access to. If any test-dev-` was pulled by a downstream transitive dependency, escalate to a broader dep-graph audit - that transitive path is the real vulnerability
  3. 3Cluster B (@moxfive-llc/common): MoxFive Inc IR customers or partners: configure .npmrc scope-to-registry mapping so @moxfive-llc resolves to a trusted internal registry, or add an explicit overrides block in package.json blocking the public-registry @moxfive-llc/common from resolving. Any lockfile hit at any version: rotate every credential the affected build had access to and audit outbound network traffic from the build host
  4. 4Cluster C (pp-react-worldready@1.0.0): any lockfile hit is a supply-chain incident - OpenSSF PA specifically flagged live outbound traffic to a known-malicious domain, indicating the payload phones out during install or import. Payments-adjacent orgs that maintain pp-* internal React namespaces: configure .npmrc scope-to-registry mapping or overrides to block the public-registry pp-* names from resolving, and audit outbound DNS from any host that resolved pp-react-worldready in the last 72h
  5. 5For every npm install in CI, run with --ignore-scripts as defense-in-depth to prevent postinstall-triggered payloads from executing during dependency installation
  6. 6Verify none of the 10 listed packages still resolves via your private mirror - internal Artifactory / Nexus / Verdaccio instances routinely cache tarballs and will keep serving the original versions after the public yank

References

Back to feedSubmit a correction
npm-2026-08-01-ghsa-malware-sweep