npm Worm Still Spreading: Check Your Servers and CI

Treat dependency installation as the exposure point

You might assume an npm package cannot compromise your server unless your application imports it. That belief fails when installation runs a malicious lifecycle script with the installing user's access. Check every machine that installed dependencies, including CI runners, before deciding your production server is clear.

In its analysis published on 4 August 2026, Microsoft describes ChainDrop, also called Mini Shai-Hulud, affecting more than 400 npm packages across unrelated publishers, including keyv, flat-cache and cache-manager. Its malicious setup.mjs runs through preinstall and launches an obfuscated Bun-based payload. Microsoft reports that the payload detaches on workstations but remains attached in CI/CD to access job secrets.

Socket's tensorlake investigation reports that tensorlake 0.5.144 was published on 8 October 2026 at 01:12:07 UTC and flagged about 11 minutes later. Its preinstall hook runs node lib/setup.mjs, which launches the payload with Bun; importing the SDK is unnecessary. That later compromise is a reason to examine recent installations, even if you already reviewed the earlier incident.

For an Ubuntu 24.04 LTS VPS, start by establishing where builds happen and which account runs them. We would pause dependency installation while investigating, including agent-initiated installs. A running application can remain available while you suspend deployment jobs, provided there is no evidence requiring immediate host isolation.

Decide which machines and credentials need investigation

Microsoft says the worm seeks npm, GitHub, AWS, Kubernetes and HashiCorp Vault credentials, alongside environment variables, SSH keys and GitHub Actions runner memory. It validates stolen credentials against service APIs. Build your rotation inventory around what the installing account could access, rather than what the application normally uses.

A short-lived runner does not make its credentials harmless. Review the permissions and lifetime of credentials available during installation, then identify downstream systems those credentials could reach. Our guide to scoped secrets for agents helps reduce that exposure when you rebuild.

Keep a private incident record containing machine identities, installation evidence and affected credential names. Do not paste token values, environment dumps or complete process environments into an agent conversation. Give Claude Code bounded inspection tasks using the approach in production agent guardrails, and retain control of credential replacement.

Inspect installed files without running package code

Begin with filesystem inspection, without launching the application or asking npm to repair dependencies. The following command searches common account and service locations for loader names and the token-monitor directory. Repeat it against your actual checkout and runner-storage locations if they live elsewhere.

sudo find /home /root /srv /opt -xdev \( -type d -name gh-token-monitor -print \) -o \( -type f \( -name setup.mjs -o -name package-lock.json -o -name npm-shrinkwrap.json -o -name yarn.lock \) -print \)

In each affected checkout, inspect the dependency tree and lockfiles without installing anything. These commands assume you are already in the real project directory with its existing Node.js tooling; they are project investigation commands, not fresh-server setup. Keep any results containing private registry addresses inside your incident record.

npm ls tensorlake keyv flat-cache file-entry-cache cacheable cache-manager --all --ignore-scripts
 git grep -n -E 'tensorlake|keyv|flat-cache|file-entry-cache|cacheable|cache-manager' -- package-lock.json npm-shrinkwrap.json yarn.lock

Read suspicious package manifests and loader files as text. Compare resolved releases with the advisories, and preserve installation logs before replacing runners or clearing caches. A matching tensorlake 0.5.144 entry establishes dependency exposure, while logs showing its hook ran establish a stronger reason to treat the machine as compromised.

Check repository hooks and runner persistence

Microsoft reports repository injection involving .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json and .vscode/setup.mjs. Inspect these files before opening a suspect checkout in an editor or starting Claude Code there. Legitimate configuration can use these paths, so investigate their contents and history rather than deleting every matching file.

git status --short --untracked-files=all
 git log --all --format=fuller -- .claude/settings.json .claude/setup.mjs .vscode/tasks.json .vscode/setup.mjs
 git diff -- .claude/settings.json .claude/setup.mjs .vscode/tasks.json .vscode/setup.mjs

Inspect other branches through your repository interface from a clean machine, without checking them out on the suspect host. Include automation branches and changes made by identities whose tokens were exposed. Protect the repaired deployment path using bounded GitHub Actions access to a VPS.

Socket identifies a Linux gh-token-monitor service with files under ~/.config/gh-token-monitor/. Run these checks under each account that installed dependencies, then inspect the system service separately. User-service inspection requires that account's functioning systemd session.

systemctl --user list-unit-files 'gh-token-monitor*' --no-pager
systemctl --user status gh-token-monitor.service --no-pager
sudo systemctl list-unit-files 'gh-token-monitor*' --no-pager
sudo systemctl status gh-token-monitor.service --no-pager
ps -eo user,pid,ppid,comm

Isolate the host before removing persistence and rotating secrets

Socket warns that the tensorlake token monitor polls api.github.com/user using the stolen token and can invoke a handler that wipes the user's home directory after revocation. Its remediation order is explicit: identify and isolate affected hosts, remove the monitor, then revoke and replace credentials before rebuilding. Do not begin recovery by revoking a token while a suspect host remains active and connected.

Use your provider's network controls or console to isolate the VPS, and take affected runners out of service. Preserve relevant evidence without executing suspect files. If you cannot confidently neutralize persistence on a live machine, keep it powered off and disconnected while arranging recovery.

For a confirmed user-scoped unit, stop and disable it under the affected account. The commands below change service state, so run them only after isolation and inspection. A system-scoped service requires the corresponding system-level action, and removing a unit does not by itself remove a running child process.

systemctl --user disable --now gh-token-monitor.service
systemctl --user is-active gh-token-monitor.service
systemctl --user is-enabled gh-token-monitor.service

Rotate credentials from a clean machine after persistence is neutralized or the affected machine is safely offline. Replace exposed SSH keys and inspect account activity for unauthorized changes. Rebuild a confirmed compromised VPS from trusted installation media; do not return the old filesystem to service after merely deleting a loader.

Patch npm on clean build machines and review script permissions

GitHub announced npm v12 availability on 8 July 2026. Its allowScripts default is off, so dependency preinstall, install, postinstall and implicit node-gyp builds require explicit permission. Updating a clean build environment reduces future installation exposure; it does not undo code execution on a compromised machine.

Use your established Node.js installation method and check npm's runtime requirements before updating. On a clean machine with a compatible runtime and a user-owned npm installation, the following installs npm v12 without package installation scripts. For a centrally managed toolchain, make the equivalent change in its image definition instead of mixing ownership with an ad hoc sudo installation.

npm install --global npm@12 --ignore-scripts
npm --version

GitHub also says npm v12 defaults --allow-git and --allow-remote to none; these behaviors showed warnings in npm 11.16.0 and later. Review blocked scripts in a clean checkout with the command below, as GitHub recommends. Commit the resulting allowlist in package.json only after reviewing each permission.

npm approve-scripts --allow-scripts-pending

Keep permissions narrow when native dependencies need build steps. Do not restore broad script execution simply to make a failing pipeline green. Review repository npm configuration and CI command-line overrides alongside the allowlist, since your effective installation policy depends on the configuration actually used.

Rebuild dependencies without restoring contaminated caches

Microsoft recommends reviewing lockfiles and CI caches, including transitive dependencies, purging npm and yarn caches, and using npm's min-release-age setting. Apply an intentional release-age policy using the official npm guidance for your installed CLI. An age delay creates review time, but it cannot establish that a dependency is trustworthy.

Preserve evidence before clearing caches, then invalidate runner caches and rebuild from a reviewed lockfile. The npm command below removes the invoking account's npm cache; it does not clean another account's cache or your CI provider's stored archives. For yarn, identify the installed tooling and follow its cache-cleaning procedure rather than guessing a command.

npm cache clean --force
npm ci --ignore-scripts

Do not rely on blocking the earlier incident's domains as your recovery criterion. Socket says the tensorlake payload resolves its command infrastructure through an Ethereum contract, with a GitHub fallback. Network controls help contain a host, but a domain blocklist cannot substitute for eliminating execution and replacing exposed credentials.

Gate the next deployment on clean build evidence

Before reopening deployment, record which clean machine produced the artifact and which reviewed commit it used. Confirm the runner reports npm v12 and that its script permissions match the committed policy. Keep build credentials separate from the production account wherever your deployment design permits.

• Confirm exposed credentials were replaced from a clean machine after affected hosts were neutralized.
• Check repository branches and automation configuration for unexpected setup execution.
• Rebuild without restoring suspect dependency caches, then run your application's normal validation.
• Deploy to the rebuilt VPS and confirm the service works with its intended permissions.

If you publish npm packages, review every package controlled by an exposed publishing identity. Microsoft describes propagation through republishing modified packages under stolen publisher access. GitHub recommends trusted publishing through OIDC or staged publishing with human approval as part of its publishing-token changes.

Make your next action a paused deployment and an inventory of machines that installed the affected dependency tree. Assign investigation by machine and credential owner so a developer laptop does not fall outside a server-focused response. Once the clean deployment works, apply the relevant checks from the Ubuntu hardening checklist before restoring routine agent access.