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)

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.

Affected packages (1)

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. 1Grep 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. 2Orgs 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. 3Audit 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. 4For every npm install in CI, run with --ignore-scripts as defense-in-depth to prevent postinstall-triggered payloads from executing during dependency installation
5. 5Verify 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

References

• GHSA-jvmj-rg3h-c654 - internallib_v688 malware advisory (dep-confusion continuation)

  github.com
  GitHub
• GHSA-2wgh-22xm-wp5f - internallib_v524 malware advisory (2026-08-03 drop)

  github.com
  GitHub
• GHSA-f4rq-x75f-gx73 - internallib_v568 malware advisory (2026-08-03 drop)

  github.com
  GitHub
• GitHub Advisory Database - recent npm malware advisories

  github.com
  GitHub