# GitHub Advisory npm CWE-506 sweep - 1-package 2026-08-04 batch (`internallib_v688` third-day continuation of the `internallib_v<NNN>` sequential dep-confusion enumeration campaign)

> GHSA published 1 npm CWE-506 advisory dated 2026-08-04: `internallib_v688` (`>= 0`) - a third-day continuation of the `internallib_v<NNN>` sequential dep-confusion enumeration campaign that dropped `internallib_v524` and `internallib_v568` on 2026-08-03. The `internallib_` prefix explicitly probes for internal-package name collisions on any org that publishes `internallib_*` internal libraries.

- Published: 2026-08-04
- Severity: high
- Kind: Advisory sweep - A dated batch of GitHub Advisory Database malware entries collected together. A sweep mixes kinds - typosquats, dependency-confusion probes, boilerplate takedowns with no published analysis, and occasionally real payloads - and its severity reflects the worst confirmed item, not the batch as a whole.
- Ecosystems: npm
- Scope: 1 package, 1 compromised version
- Tags: dependency-confusion, ci-cd-compromise, credential-theft
- Also known as: 2026-08-04 GHSA npm batch, internallib_v<NNN> sequential enumeration campaign
- Detected by: GitHub Advisory Database, OpenSSF Package Analysis, npm Security
- Incident ID: npm-2026-08-04-ghsa-malware-sweep

## Affected packages (1)

Only the exact versions listed were named by the source advisories. Other versions are not implicated.

| Package | Ecosystem | Compromised versions |
|---|---|---|
| [internallib_v688](https://dependencywatch.io/package/npm/internallib_v688) | npm | 1.0.0 |

## What happened

On 2026-08-04, the GitHub Advisory Database published **1 new npm CWE-506 (Embedded Malicious Code) advisory**: `internallib_v688`. Small single-package batch, but the drop is a **direct continuation of the `internallib_v<NNN>` sequential dep-confusion enumeration campaign** that dropped `internallib_v524` and `internallib_v568` on 2026-08-03 (see `npm-2026-08-03-ghsa-malware-sweep` Cluster E).

## Cluster A - `internallib_v688` third-day continuation of `internallib_v<NNN>` sequential dep-confusion campaign (1 package, 2026-08-04)

| Package | Notes |
|---|---|
| `internallib_v688` | `internallib_v<NNN>` sequential dep-confusion probe, third-day continuation |

GHSA-jvmj-rg3h-c654 carries the standard CWE-506 boilerplate ("any computer that has this package installed or running should be considered fully compromised - rotate all secrets from a different computer") with no per-package behaviour prose.

The `internallib_v<NNN>` naming template is a **canonical dep-confusion probe** against orgs that publish internal `internallib_*` packages to their private registry. The explicit `internal` prefix is an unambiguous naming tell - no reasonable developer would type `npm install internallib_v688` intending to install a public library - so the operator is targeting **internal-tooling namespaces specifically**, relying on organisations misconfiguring `.npmrc` scope precedence or `--registry` flags so that the public malicious version resolves over the internal legitimate one.

## Campaign shape

Three confirmed variants across two days:

| Version tag | Published | GHSA |
|---|---|---|
| `internallib_v524` | 2026-08-03 | GHSA-2wgh-22xm-wp5f |
| `internallib_v568` | 2026-08-03 | GHSA-f4rq-x75f-gx73 |
| `internallib_v688` | 2026-08-04 | GHSA-jvmj-rg3h-c654 |

The non-sequential numeric progression (`v524` → `v568` → `v688`) suggests the operator is **not enumerating exhaustively but sampling from ranges** - possibly correlated to real version numbers observed in leaked or scraped internal package manifests (e.g. a Slack / Discord leak that mentioned an `internallib_v524` internal package inside a target org), or simply randomised to avoid trivial takedown pattern matching on sequential names.

Adjacent-day drops with fresh numeric suffixes indicate an operator running a **numeric-suffix enumeration loop** where every fresh `v<NNN>` version is a new attempt to catch an internal-registry misconfiguration. The operator will almost certainly continue publishing fresh `v<NNN>` variants over the next several days - future daily GHSA batches should be watched for additional `internallib_v*` drops under the same campaign shape.

## Registry state

Package security-replaced during the 2026-08-04 batch. Original version tarball no longer resolvable on the public registry, but private mirrors (Verdaccio, Artifactory, Nexus) that cached the tarball BEFORE the takedown WILL keep serving the original version.

## Related tracked activity

- Direct continuation of `internallib_v524` and `internallib_v568` catalogued in `npm-2026-08-03-ghsa-malware-sweep` Cluster E - same operator, same enumeration campaign against `internallib_*` internal packages.
- Matches the broader **internal-tooling dep-confusion sweep** pattern documented across the 2026-07-2x through 2026-08-0x batches (`beaver-ui-*`, `accounts-final-form`, `accounts-loading-state`, `bigops-chat-messages`, `fluid-type-ui`, `lifestyle-test-utils`, `@custombots/custombot`, `list-issue-predecessor-dependencies-block`, etc.) - the operator ecosystem is running coordinated internal-namespace enumeration bursts against real target orgs.
- No `threatActor` field is set - GHSA advisory uses only CWE-506 boilerplate with no named actor attribution.

## Impact

- Any host that installed `internallib_v688` should be treated as fully compromised - GHSA-jvmj-rg3h-c654 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 - `internallib_v688` third-day continuation of `internallib_v<NNN>` sequential dep-confusion campaign** (1 package, `>= 0`, 2026-08-04): `internallib_v688`. Direct continuation of the `internallib_v524` + `internallib_v568` pair dropped one day earlier under the 2026-08-03 batch (see `npm-2026-08-03-ghsa-malware-sweep` Cluster E). The `internallib_v<NNN>` naming template is a **canonical dep-confusion probe** against orgs that publish internal `internallib_*` scoped or unscoped packages to their private registry - the explicit `internal` prefix is a naming tell that the operator is targeting internal-tooling namespaces specifically
- The non-sequential numeric progression (`v524` → `v568` → `v688`) suggests the operator is not enumerating exhaustively but sampling from ranges - possibly correlated to real version numbers observed in leaked or scraped internal package manifests, or simply randomised to avoid trivial takedown pattern matching. Adjacent-day drops with fresh numeric suffixes indicate an operator running a **numeric-suffix enumeration loop** where every fresh `v<NNN>` version is a new attempt to catch an internal-registry misconfiguration
- Package no longer retains its original tarball on the public npm registry - replaced with security sentinel during takedown. Private registry mirrors (Verdaccio, Artifactory, Nexus) that cached the tarball BEFORE the takedown WILL keep serving the original version

## What to do

1. Grep every lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`) for `internallib_v688`, `internallib_v568`, and `internallib_v524` together - treat all three as a single dep-confusion campaign against `internallib_*`. Any match is a supply-chain incident: rotate every credential the build runner could reach and re-image the build host
2. Orgs that maintain a real internal `internallib_*` package namespace: configure `.npmrc` scope-to-registry mapping or `overrides` block in `package.json` to prevent the public-registry `internallib_v<NNN>` variants from resolving preferentially over the internal versions. The operator will almost certainly continue publishing fresh `v<NNN>` variants over the next several days - a durable `overrides` block on the entire `internallib_v*` glob (if your resolver supports it) or an explicit block-list of all currently-known malicious variants is the correct defense
3. Audit outbound network from any build host that resolved any of `internallib_v524`, `internallib_v568`, `internallib_v688` in the last 72h - the CWE-506 boilerplate implies unknown behaviour, so treat every network connection during the install window as suspect until proven otherwise
4. For every npm install in CI, run with `--ignore-scripts` as defense-in-depth to prevent postinstall-triggered payloads from executing during dependency installation
5. Verify `internallib_v688` does not still resolve via your private mirror - internal Artifactory / Nexus / Verdaccio instances routinely cache tarballs and will keep serving the original versions after the public yank

## Check your own dependencies

- Check a package-lock.json against this incident: https://dependencywatch.io/check/package-lock-json

The scan runs entirely in the browser; lockfile contents are never uploaded.

## References

- [GHSA-jvmj-rg3h-c654 - internallib_v688 malware advisory (dep-confusion continuation)](https://github.com/advisories/GHSA-jvmj-rg3h-c654) - GitHub
- [GHSA-2wgh-22xm-wp5f - internallib_v524 malware advisory (2026-08-03 drop)](https://github.com/advisories/GHSA-2wgh-22xm-wp5f) - GitHub
- [GHSA-f4rq-x75f-gx73 - internallib_v568 malware advisory (2026-08-03 drop)](https://github.com/advisories/GHSA-f4rq-x75f-gx73) - GitHub
- [GitHub Advisory Database - recent npm malware advisories](https://github.com/advisories?query=type%3Amalware+ecosystem%3Anpm&sort=published-desc) - GitHub

---

Canonical page: https://dependencywatch.io/incident/npm-2026-08-04-ghsa-malware-sweep
Markdown version: https://dependencywatch.io/incident/npm-2026-08-04-ghsa-malware-sweep.md
Site index for agents: https://dependencywatch.io/llms.txt
DependencyWatch.io is operated by Precursor Security (https://precursorsecurity.com).