What happened
On August 4, 2026, Socket placed the first malicious keyv/cacheable release at 09:35 UTC. By August 5, 2026, SANS ISC reported public IOC lists covering more than 440 packages across more than 2,000 versions. The preinstall hook runs setup.mjs, which downloads a standalone Bun runtime and executes the approximately 728 KB file Math_Symbol.js. Analysis described collection attempts against AWS instance metadata, cloud keys, Vault tokens, Kubernetes service-account tokens, GitHub Actions secrets, npm tokens, private keys and bearer tokens. Stolen npm publishing access was then used to inject the hook into additional packages and republish them. Attribution posture: The cited research does not establish a responsible actor for the keyv/cacheable npm compromise.
The cited sources identify Claude Code repository hooks and Visual Studio Code workspace tasks as execution surfaces. The attacker added a SessionStart entry to .claude/settings.json and a folderOpen task to .vscode/tasks.json. Opening a poisoned repository could mechanically invoke the loader without npm install. The underlying Claude model and version were not identified in the cited sources. The persistence directory is ~/.config/gh-token-monitor/, with the watcher installed as a macOS LaunchAgent or Linux systemd user service. The watcher checks the GitHub API every 60 seconds and executes an attacker-supplied handler after an HTTP 4xx response. That response can be produced by revoking the stolen token, which means an otherwise normal containment action may trigger additional code unless the host is isolated and the watcher removed first.
Why this matters now
The executive risk is not confined to whether a malicious package appears in a software bill of materials. A developer endpoint, shared runner or investigation workstation may have executed the payload while installing a transitive dependency or simply opening a poisoned repository. Those environments often hold the identities that publish software, approve code, access cloud control planes and retrieve deployment secrets. The worm therefore connects software provenance, endpoint compromise and privileged identity into one incident path. A passing build attestation does not close the issue because a legitimate workflow can faithfully build source that was already modified.
Containment sequencing is unusually consequential. Immediate token revocation is normally a defensible first move after credential theft, but the watcher described by SANS treats token invalidation as its execution condition. Security leaders should require one coordinated response plan across incident response, engineering, identity, cloud and package-management teams rather than allowing each team to rotate its own credentials independently. The business consequence is broader than the affected workstation: stolen npm or GitHub authority can poison downstream releases, while exposed cloud or Kubernetes credentials can create a second incident outside the development environment.
The decision for security leaders
Declare a scoped supply-chain incident when an affected package version, execution artefact or persistence mechanism is found. The first authorised step should be network isolation without shutdown, preserving volatile evidence and preventing further exfiltration while avoiding the HTTP response that activates the watcher. The incident-response lead should then preserve the watcher directory, handler text, payloads, service definitions, package caches and repository hooks. Only after the trigger is disabled should identity owners revoke credentials in a documented order, beginning with publishing authority and continuing through source control, cloud, Vault, Kubernetes and CI secrets.
Separate dependency remediation from compromise closure. Removing a package, pinning a clean version or clearing a cache proves only that future builds should not resolve the known artefact. It does not prove that the payload never executed, that persistence is absent, that credentials were not taken or that compromised publishing identities made no downstream changes. Engineering leadership should freeze releases from affected identities until registry, GitHub and cloud audit records are reconciled. Legal and executive escalation should follow evidence of unauthorised publication, production credential use, destructive handler content or material data access.
Evidence of closure
- Forensic images contain the watcher directory, payloads and service definitions.
- Endpoint validation finds no surviving LaunchAgent, systemd service or repository hook.
- Registry and GitHub audit logs show no unexplained publication or repository modification.
- All credentials accessible during the bounded exposure window have documented revocation evidence alonf with confirmations of invalidation where applicable, ensuring no residual access remains and supporting closure assessment from identity and platform owners.
The Security.io assessment
The cited sources did not publish the runtime handler content, so its final action is unresolved. That uncertainty argues for controlled evidence preservation, not speculation that the handler is necessarily destructive. The demonstrated behaviours already justify incident treatment: credential discovery, propagation through trusted publishing access, repository-opening execution and a remotely supplied command trigger. The absence of a published victim count also prevents a defensible estimate of enterprise impact. Organisations should base escalation on local execution and identity evidence rather than ecosystem download statistics alone.
The most important governance lesson is that software provenance is necessary but not sufficient. A valid attestation can establish that an approved workflow built an artefact; it cannot establish that the source entering that workflow was benign. Repository configuration directories must also be treated as executable policy, particularly when developer tools or coding agents honour them automatically. Closure therefore requires proof across four planes: clean dependency resolution, eradicated endpoint persistence, invalidated credentials and reconciled publishing activity. Any one of those without the others leaves a credible path for continuing compromise.
Questions for the morning meeting
- Can engineering identify every build and workstation that resolved the affected dependency graph?
- Who can authorise isolation before the normal credential-rotation workflow begins?
- Which production credentials were reachable from affected developer or CI contexts?
- Can the organisation prove that trusted attestations did not mask trojanised source?