A poisoned npm release that punishes you for revoking the stolen token. The order of your response is the whole defence.
Most incident guidance starts with revoking the leaked token. Here that is the trigger. What StepSecurity found, the order it recommends, and why a valid provenance attestation did not help.
- Package
- tensorlake on npm, version 0.5.144
- First malicious commit
- 7 October 2026, 01:20 UTC, to main, under a maintainer name
- Published to npm
- 8 October 2026, 01:12 UTC, by the repository release workflow
- Runs at
- Install time, through a preinstall hook. Skips CI
- The trap
- gh-token-monitor checks the stolen token every 60 seconds for up to 24 hours and deletes the home directory if it is rejected
- Provenance
- Valid npm attestation. It says where the package was built, not that it is safe
- Registry today
- npm no longer lists 0.5.144. Latest listed is 0.5.151
What happened, in order
StepSecurity reports that someone pushed malicious files straight to the main branch of tensorlakeai/tensorlake under a maintainer name, at 01:20 UTC on 7 October. Seven more commits followed over the next few hours, tweaking the payload and adding a preinstall line to package.json, and none of them went through a pull request. At 01:12 UTC on 8 October the repository release workflow published tensorlake 0.5.144 to npm, started under the same maintainer identity. The files in the npm package match the files on main.
The sources we read do not say how the commits were pushed, meaning whether a maintainer account, a token or something else was used. We are not going to guess. What they do establish is that the release came from the project repository and its release workflow.
What the install does
When the package is installed, the preinstall hook runs setup.mjs. It skips itself on CI, so developer machines are the target. It downloads the Bun runtime and uses it to run an obfuscated 856 KB file that StepSecurity decoded without running.
The payload goes after GitHub and npm tokens, cloud keys, Kubernetes and Vault secrets, SSH keys, saved browser logins, and configuration files for AI tools including Claude, Cursor and Windsurf. The data is encrypted and sent to a public GitHub repository the malware creates in the account of the victim, described as "Shai-Hulud: Here We Go Again", or to a domain it controls.
It then tries to spread. With a stolen npm token it downloads the packages that token can publish, adds itself, bumps the version and republishes them. With a stolen GitHub token it commits .claude/settings.json and .vscode/tasks.json files to the repositories it can reach under a fake claude@users.noreply.github.com author with the message "chore: update dependencies", so the payload runs again when someone opens the project in Claude Code or VS Code.
The trap, and why the order matters
If the malware has a GitHub token, it installs a small service called gh-token-monitor. Every 60 seconds, for up to 24 hours, the service checks the token against the GitHub API. If GitHub rejects it, the service runs rm -rf ~/ on Linux and macOS, or deletes the user profile with PowerShell on Windows. StepSecurity puts it plainly: the obvious first move, revoking the token, is what sets it off.
That reverses the usual advice. StepSecurity says that if you installed 0.5.144, you should not revoke any tokens yet. Back up anything you cannot lose, remove the monitor, and only then rotate credentials.
- Check whether you have it: run npm ls tensorlake and look in lockfiles for 0.5.144, and consider whether you cloned or pulled the repository main since 7 October and ran npm install in typescript/.
- Look for the folder ~/.config/gh-token-monitor/. If it exists, open the token file inside to see which GitHub token it holds, then stop and remove the service. On Linux the files are under ~/.config/gh-token-monitor, ~/.local/bin/gh-token-monitor.sh and ~/.config/systemd/user/gh-token-monitor.service. On macOS there is a launch agent called com.user.gh-token-monitor.plist.
- Only then rotate: GitHub and npm tokens, cloud keys, SSH keys, Kubernetes and Vault credentials, secrets in .env files, AI tool keys and passwords saved in the browser.
- Check for spread: new public repositories on your account with the Shai-Hulud description, commits from claude@users.noreply.github.com, and .claude or .vscode files you did not add.
Provenance did not help, and install scripts did the damage
The release carries a valid npm provenance attestation, because it really was built from the project repository. StepSecurity is direct about what that means: "The attestation says where a package was built. It doesn't say the code is safe." A policy that trusts provenance alone would have let this through.
The delivery mechanism was an install script. StepSecurity notes that setting ignore-scripts=true in .npmrc stops install hooks like this one. The tradeoff is that some legitimate packages need their install scripts, so turn it on, find what breaks, and allow those packages deliberately.
What to do
- 1Run npm ls tensorlake and search lockfiles for 0.5.144 across every repository and CI cache.
- 2If it was ever installed, do not revoke the GitHub token first. Back up what you need, remove gh-token-monitor, then rotate.
- 3Rotate every credential the machine could reach, including AI tool keys and browser saved passwords.
- 4Search your GitHub account for the Shai-Hulud repository description and for commits from claude@users.noreply.github.com.
- 5Set ignore-scripts=true in .npmrc and allow install scripts per package.
- 6Pin tensorlake to 0.5.143 if you must use it, as StepSecurity suggests, and treat newer releases with care until the maintainers publish an incident note.
Common questions
Is it safe to revoke the stolen GitHub token?
Not first. StepSecurity says the malware installs a monitor that deletes the home directory if GitHub rejects the token, so the monitor has to be removed before the token is revoked.
Does npm provenance mean a package is safe?
No. The attestation records where the package was built. This release was built from the project repository, so it carries a valid one. StepSecurity says it does not say the code is safe.
Is version 0.5.144 still on npm?
No. As of 15 October the npm registry no longer lists 0.5.144, and the latest listed version is 0.5.151. Copies already installed or cached on machines are not affected by that removal.
Does this affect CI?
The setup script skips itself on CI according to StepSecurity, so developer machines are the target. CI caches and lockfiles are still worth checking.
Sources
Read against the primary documentation rather than secondary coverage. Where a figure comes from a provider's own docs, it is quoted as published on 2026-10-15.
Related
More from Signals
Open the tool.
Ten production categories, three minutes, and a ranked list of what to fix first.
Check your own stack