GitHub Advisory npm malware sweep, 21 July 2026

The full picture

6 packages 43 versions

• npm@apexfdn/apex1.0.01.0.11.0.21.0.31.0.41.0.51.0.61.0.71.0.81.0.91.0.101.0.111.0.121.0.131.0.141.0.151.0.161.0.171.0.181.0.191.0.201.0.211.0.221.0.231.0.241.0.251.0.261.0.271.0.281.0.291.0.301.0.311.0.32→
• npmnolby1.0.01.0.11.0.21.0.3→
• npmstreak-calendar1.0.01.0.1→
• npmstreak-daycount1.0.0→
• npmsvelte-streaks1.0.01.0.11.0.2→
• npmveskra→

What it does if you installed it

• Any host that installed any of the packages below should be treated as fully compromised - every GHSA record uses the boilerplate CWE-506 "rotate all secrets from a different computer" language, and no patched version exists
• *`streak- habit-tracker cluster** (3 packages): streak-daycount@1.0.0 (published 2026-07-21 14:56:04 UTC), streak-calendar@1.0.0/1.0.1 (2026-07-21 15:17:37 → 15:52:37 UTC), and svelte-streaks@1.0.0/1.0.1/1.0.2 (2026-07-21 14:56:14 → 15:52:49 UTC) were all published within a 56-minute window and security-replaced with 0.0.1-security` sentinel tarballs in a tight 27-second window at 2026-07-21 23:16:35 → 23:17:02 UTC - a coordinated single-actor pattern. The shared "streak" habit-tracker theme (day-count / calendar / Svelte streak widget) and near-identical publish→take-down cadence indicate a single publisher exercising a specific target scope
• @apexfdn/apex 33-version dependency-confusion burst (1 package): 33 versions 1.0.0 → 1.0.32 published across 17 days from 2026-07-05 → 2026-07-21, then npm-security-replaced 2026-07-21 UTC. The @apexfdn scope name is unregistered on public npm - the sustained multi-day publish cadence at monotonically incrementing patch levels fits a classic dependency-confusion pattern where the operator keeps publishing higher patches to survive a specific resolver behavior (some resolvers cache-invalidate on version bump, others don't). The scope apexfdn reads as "Apex Foundation" - a likely internal-registry scope name at a specific organisation. Any lockfile pin on @apexfdn/apex indicates the resolver picked the public malicious tarball over the intended private one
• nolby 4-version rapid-burst (1 package): 4 versions 1.0.0 → 1.0.3 published within 3h 45min on 2026-07-21 (05:42:46 → 09:27:35 UTC), then security-replaced 2026-07-21 17:00:39 UTC. The tight version-bump cadence in the same day, plus the choice of a short unregistered name, is characteristic of a single operator iterating on a payload while probing a specific resolver behavior
• veskra singleton (1 package): the pre-existing veskra name was directly npm-security-replaced 2026-07-21 17:00:45 UTC with no visible original version metadata still in the registry - indicating the original tarball was pulled before the security-holder replacement, and only the sentinel tarball remains publicly resolvable. Any lockfile that pinned veskra at any version prior to 0.0.1-security is affected
• None of the 6 packages have surviving version tarballs on the public npm registry - all replaced with 0.0.1-security sentinel tarballs. Private registry mirrors (Verdaccio, Artifactory, Nexus) that cached the tarballs during the publish window WILL keep serving the original versions after the public yank - lockfile hits on these names must be treated as actionable regardless of what the public registry currently returns

Clean-up steps

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. 2If you had streak-daycount, streak-calendar, or svelte-streaks in a lockfile: the near-simultaneous publish→take-down cadence across the three names indicates a single coordinated actor. Rotate npm, GitHub, and CI/CD tokens the install could have reached; audit postinstall logs for the ~8-hour exposure window between publish (14:56 UTC) and security-replacement (23:16 UTC) on 2026-07-21
3. 3If you had @apexfdn/apex in a lockfile: this strongly indicates a misconfigured internal-registry resolver - the @apexfdn scope is unregistered on public npm and reads as an internal "Apex Foundation" scope. Audit the resolver order in .npmrc (private registry MUST be listed before the public registry for internal-scope names), register @apexfdn defensively on the public npm registry if your org uses that scope internally, and consider tightening .npmrc to @apexfdn:registry=https://<private-registry>/ so the public registry is never queried for this scope. Any of the 33 published versions 1.0.0 → 1.0.32 should be treated as compromised
4. 4If you had nolby in a lockfile: any of the four versions 1.0.0 → 1.0.3 should be treated as compromised. The publish times cluster in a 4-hour window, so a lockfile pinned to any of them received the same payload family
5. 5If you had veskra in a lockfile: only 0.0.1-security remains resolvable - the original version(s) were pulled from the public registry before the sentinel replacement. Grep every lockfile for veskra at any non-0.0.1-security version and treat any hit as actionable
6. 6Verify none of the 6 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
7. 7For projects using postinstall-scripting packages, consider running npm install --ignore-scripts in CI as a defense-in-depth measure and re-invoking scripts only for vetted first-party packages

Sources

• GitHub Advisory Database - recent npm malware advisoriesgithub.comGitHub
• GHSA-2v57-6hmf-hpfj - streak-daycount malware advisorygithub.comGitHub
• GHSA-8vq2-5c69-fm3w - svelte-streaks malware advisorygithub.comGitHub
• GHSA-2p69-mmpj-h84r - streak-calendar malware advisorygithub.comGitHub
• GHSA-w63r-vpcf-2wwf - @apexfdn/apex malware advisorygithub.comGitHub
• GHSA-pr2p-6xpw-q8vw - veskra malware advisorygithub.comGitHub
• GHSA-x724-q7wp-wx6q - nolby malware advisorygithub.comGitHub