[email][email protected][/email], [email][email protected][/email], [email][email protected][/email], and a growing list of other npm releases must be treated as compromise indicators after a maintainer-account takeover seeded a credential-stealing worm across more than 400 packages on August 4. The immediate task for Windows development and build teams is not a routine dependency upgrade: determine whether any affected release was installed or executed on a workstation, build runner, or CI agent, then rotate the credentials that machine could read. Wiz Research first detailed the incident, saying the attacker used a compromised GitHub maintainer identity to add persistence code to the Keyv repository beginning around 09:00 UTC, then published the tainted [email][email protected][/email] release shortly afterward. Wiz’s published affected-version list also includes @cacheable/[email][email protected][/email], [email][email protected][/email], and numerous packages outside the original Keyv and Cacheable projects, including Qlik and Ornikar packages. The list has continued to expand through Wiz’s GitHub tracking file.
The important finding is the worm’s target selection. This payload is designed to take developer and automation credentials, then use them to widen the breach. It searches for cloud, source-control, CI/CD, AI-tool and cryptocurrency secrets; it can create repositories under compromised GitHub identities to hold stolen data; and it attempts persistence through Claude Code hooks and Visual Studio Code tasks.json files. A Node.js dependency incident has therefore become a developer-endpoint and build-system incident.

Cybersecurity illustration showing a malicious package infecting software, cloud services, servers, and blockchain networks.A compromised lockfile is a lead, not the whole verdict​

Teams should immediately search package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, dependency caches, artifact stores, and built container images for the named malicious versions. But a lockfile hit alone does not establish that the payload ran. It establishes that a project was capable of resolving the compromised artifact; the decisive questions are whether npm install, npm ci, a package-manager restore, or an equivalent build step actually occurred while the bad version was available.
That distinction changes the incident response. A repository committed with [email][email protected][/email] in a lockfile but never restored may need a dependency correction and a review of package-cache policy. A Windows developer laptop or hosted runner that performed the restore must be handled as potentially compromised because the malware’s value lies in collecting secrets present at execution time.
For Windows shops, the practical evidence will often be scattered across CI logs, developer shell history, local npm caches, package-manager caches, build-agent workspaces, and EDR telemetry rather than in a single server log. Review activity from August 4 onward for fresh dependency restores, especially jobs that install dependencies without using an established internal mirror or a locked, pre-approved artifact set. Preserve the relevant workspace and logs before clearing caches: package contents, timestamps, process trees, and outbound connections may be the only evidence of what ran.
Wiz identifies Math_Symbol.js under node_modules/keyv, a temporary /tmp/bun-dl-* path, and the Bun/1.3.13 user agent among the campaign indicators. The Linux-style temporary path should not be mistaken for a Windows exclusion. Windows developers can still pull the same dependency in WSL, containers, Git Bash environments, remote development hosts, or CI runners running Linux. More broadly, the VS Code persistence component crosses platform boundaries because a checked-out repository and editor configuration can follow a developer between Windows, macOS, Linux, dev containers, and remote SSH targets.

The attacker moved the command channel off the package registry​

According to Wiz’s malware analysis, this version retrieves command-and-control domains through an Ethereum smart contract using an eth_call, rather than carrying a fixed list of attacker domains in the package. That is an operational advantage for the attacker: an indicator embedded in a static package can be blocked or sinkholed, while a blockchain-hosted lookup can redirect infected machines to new infrastructure without republishing the malicious npm release.
Wiz reported that the contract initially returned three domains and was later changed to return npm-cache[.]com. The company also named Ethereum RPC services used for the lookup, including NodeReal, GetBlock, and LlamaRPC. Defenders should be careful with that list. Blocking a public Ethereum RPC endpoint across an enterprise may cause collateral damage and will not repair an already exposed credential. The more valuable detection logic links unusual Node.js or Bun processes to Ethereum RPC calls immediately after dependency installation, then checks whether the same host contacted the reported exfiltration infrastructure.
The payload’s use of a selective dead-man’s switch deserves equal attention. Wiz says the command server can instruct the malware to monitor a token by testing whether it remains valid against GitHub’s user API, and to react if that token is revoked. In plain terms, the malware is built to notice parts of the response process. That makes rapid revocation necessary, but it also means responders should collect evidence and identify downstream abuse before assuming that disabling one token closes the incident.
The attacker also changed the exfiltration encryption key while keeping a separate RSA key for validating fallback command-and-control material posted to GitHub, Wiz reported. That separation is a sign of an operator maintaining a reusable malware framework, not an opportunistic one-off modification. Wiz characterizes the code as a descendant of the publicly released “Mini” Shai-Hulud family associated with prior TeamPCP-related campaigns; it has not presented this as a final attribution of the Keyv compromise itself.

IDE persistence turns source trees into an endpoint risk​

The VS Code portion of this campaign means security teams need to inspect more than node_modules. Wiz says the malware attempts persistence through .vscode/tasks.json and Claude Code hooks, using files called setup.mjs. A malicious task placed in a project can execute when a developer opens, trusts, or interacts with the workspace, depending on the task configuration and local editor settings.
That creates a second containment problem: removing the malicious package version may leave behind a modified repository. Developers who clean node_modules, rerun the package manager, and continue working in an existing checkout could still retain hostile editor configuration. Repositories and working directories touched by an affected install should be examined for new or changed .vscode and .claude content, unexpected workflow files, altered package scripts, and suspicious commits carrying generic messages such as chore: update config.
Wiz reported an intimidation string embedded in initial commits: IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients. Treat that as a detection artifact, not a credible operational warning. The attacker benefits if responders hesitate to revoke a token. A legitimate service should never depend on an unreviewed credential embedded by an unknown party; if revocation breaks production, that exposes a separate and serious secret-management failure that needs correction.
The more difficult possibility is that stolen GitHub or npm credentials were used to publish additional poisoned versions elsewhere. That is why an investigation cannot stop with the Keyv and Cacheable namespaces. Review GitHub audit logs for new personal access tokens, OAuth grants, deploy keys, newly created repositories, unfamiliar Actions workflow changes, altered branch protections, and package publication activity. Review npm organization logs and trusted-publishing configuration as well. The worm’s purpose is propagation, so a compromised publishing identity can become the next distribution point.

Rebuild exposed builders and rotate secrets in dependency order​

Wiz recommends rebuilding affected systems and rotating cloud credentials, GitHub tokens, SSH keys, Kubernetes configurations, Terraform credentials, and other developer secrets. That is the correct baseline for hosts where execution is confirmed or cannot be ruled out. Removing a JavaScript file does not demonstrate that copies of its collected secrets were not already exported.
Prioritize credentials by what could have multiplied the incident:
  • Revoke and replace GitHub personal access tokens, GitHub App credentials, deploy keys, npm publishing tokens, and CI secrets with repository or package publication authority.
  • Rotate cloud access keys, workload credentials, Kubernetes credentials, Terraform state access, registry passwords, and secrets available to the affected build identity.
  • Examine access logs for those credentials before and after rotation, because the attacker may have used valid secrets quickly.
  • Rebuild developer workstations and build runners where the malicious package ran, rather than relying on a file-level cleanup.
  • Revoke or review editor integrations and AI coding-tool credentials stored on affected machines, including credentials for Claude, OpenAI, Codex, Cursor, and Gemini that Wiz says the malware explicitly targets.
There is no CVE that patches this event, and npm audit alone is not a sufficient test for it. This was a publication compromise involving specific package versions and an actively maintained affected-package list, not a conventional vulnerable-code flaw with one stable advisory identifier. The control that would have limited the blast radius is a release-age gate, vetted internal registry, dependency allowlist, immutable lockfile enforcement, and strict separation between build credentials and publishing credentials.
The concrete danger now is not merely that developers installed a bad caching library. It is that a routine restore may have handed an attacker the keys to GitHub, npm, cloud accounts, CI infrastructure, and editor tooling—then planted a mechanism intended to survive after the dependency itself is removed.

References​

  1. Primary source: wiz.io
    Published: 2026-08-04T11:25:22+00:00
  2. Related coverage: wiz.io
  3. Related coverage: npmjs.com
  4. Related coverage: threats.wiz.io
  5. Related coverage: npmjs.com
  6. Related coverage: cloud.google.com
  7. Related coverage: labs.cloudsecurityalliance.org
  8. Related coverage: labs.cloudsecurityalliance.org
  9. Related coverage: techradar.com
  10. Related coverage: cacheable.org
  11. Related coverage: infoworld.com
  12. Related coverage: attestd.io
  13. Related coverage: protoslabs.io
  14. Related coverage: assets.kpmg.com
  15. Related coverage: socket.dev
  16. Related coverage: socket.dev
  17. Related coverage: aikido.dev