Shai-Hulud Hit Tensorlake's npm Package: How to Check Your Builds and Rotate Secrets Safely
A poisoned release of an AI sandbox SDK was live for hours. Here is how to find out whether it touched your machines, and why the order of your cleanup matters.
On this page 8 sections
A Shai-Hulud variant was published inside tensorlake version 0.5.144 on npm on October 8, 2026. Its install script steals cloud, CI and browser credentials and can wipe a machine if a stolen token is revoked. If any system installed that version, treat it as compromised, disable the token monitor, then rotate every secret it could read.
Backtrace covers the security work that engineering teams actually do, and this incident is a clean example of why install-time code is a risk. This guide is for developers, DevOps engineers and platform leads who use npm. It covers what happened, how to check your exposure, how to clean up in a safe order and how to cut the odds of a repeat.
What Happened to the Tensorlake npm Package?
An attacker published a poisoned release of Tensorlake's npm SDK after gaining control of a maintainer's identity. According to Aikido Security's analysis, the actor made verified commits under a maintainer's identity on October 7 and added the malicious code by direct file upload. The poisoned version reached npm on October 8, about 20 hours after the repository was compromised.
Socket flagged the release 11 minutes after publication. npm removed the version, and Tensorlake published 0.5.145 as a clean replacement. The Register's report says the package gets about 12,000 downloads a week and that the full impact is unknown. Aikido cites a much higher lifetime install count, so exposure estimates vary.
The Register adds that the code shares techniques with the ChainDrop variant used in August against packages such as keyv and flat-cache. This is a known family, not a new one.
How Does This Shai-Hulud Variant Work?
It runs when you install the package, not when you import it. A preinstall script launches a setup file that installs the Bun runtime and then runs a second payload with it. That is why a plain install on a laptop or a build server is enough.
The payload harvests environment variables and local secrets, mainly cloud, CI, Kubernetes and Vault credentials. It also reads credential files such as SSH keys and cloud configs. Unlike earlier waves, Aikido says it targets 14 cryptocurrency wallet browser extensions and downloads a tool to pull saved logins from browsers.
Socket's warning explains the stakes: code executed during installation inherits the permissions of the installing process. A build agent with deploy keys hands those keys to the attacker.
The nastiest feature is the dead-man's switch. The malware monitors stolen GitHub tokens. If one is revoked, it can delete data on the infected machine. Researchers advise disabling the token monitor before revoking credentials.
How Do You Check Whether You Were Exposed?
Search your lockfiles, CI logs and caches for the bad version. Start with the repositories that use Tensorlake directly, then check transitive dependencies. Work through these checks in order:
- Run npm ls tensorlake in each project and read the resolved version.
- Search every package-lock.json, yarn.lock and pnpm-lock.yaml for tensorlake and the string 0.5.144.
- Check CI install logs from October 8 onward for that version, including scheduled and bot-triggered builds.
- Check developer machines and shared build caches, not just pipelines.
- Look for the indicators Aikido published, including the file lib/Math_Symbol.js and the domain iseekaigogo[.]com.
Developer laptops and CI runners fail differently. A laptop usually holds personal cloud profiles, SSH keys and browser logins, so the exposure is broad but one person wide. A shared runner may hold deploy keys for many services, so one install can reach a lot of systems at once. Prioritize shared runners and release machines first, then work down to individual laptops.
A match on 0.5.145 or later is not an infection. A match on 0.5.144 means the install script may have run. If you cannot prove it did not, assume it did.
Outbound network logs help too. Any request to the listed command-and-control domain from a build host is a strong signal. Our guide on secrets scanning tools can help you find what was exposed on affected systems.
What Is the Safe Order for Cleanup?
Contain first, rebuild second and rotate third, with token revocation last. Doing it out of order can trigger the wipe or leave the attacker with live keys. Socket recommends rebuilding compromised systems from a trusted source before restoring access to secrets.
Follow this sequence for each affected machine or runner:
- Isolate the system from the network and from your secret stores.
- Stop any process that watches for token revocation, following your security vendor's guidance.
- Snapshot or copy logs you need for the investigation.
- Rebuild from a known-good image; do not clean in place.
- Rotate every credential the system could read, starting with cloud and CI tokens.
- Review audit logs for use of those credentials since October 8.
The rotation list is long on purpose. Cloud keys, GitHub and package registry tokens, SSH keys, Kubernetes and Vault tokens, and any .env contents all count. Our API key rotation guide covers how to do this without breaking production.
Do not forget secrets that live outside code. Shared password vaults, chat bots and deployment dashboards often hold copies of the same keys. If a stolen credential was also pasted into one of those places, rotating only the original leaves a working copy behind.
Document what you did and when. If an auditor or customer asks, a written timeline is worth more than good memory.
How Can You Reduce Install-Time Risk Going Forward?
Stop dependencies from running code on install unless you approve it. Setting ignore-scripts to true in npm blocks lifecycle scripts like preinstall for packages you pull in. Recent versions of pnpm also block dependency lifecycle scripts by default and let you allow specific packages.
A few controls add up. Use exact versions and lockfiles, and review lockfile changes in pull requests. Delay adoption of brand-new releases with a minimum release age setting where your package manager supports it, since most poisoned versions are caught within hours.
Give CI the least access it needs. A build runner should not hold production deploy keys. Short-lived, scoped tokens limit what a stolen environment can do. Our overview of software supply chain attacks explains the wider pattern.
AI tooling adds new routes in. The Tensorlake SDK exists to run untrusted, AI-generated code in sandboxes. A sandbox does not help if the SDK's own install step runs outside it. We looked at a related risk in hallucinated dependencies.
What This Incident Says About Maintainer Account Security
The weak point was not the registry but the people and pipelines around the package. Verified commits under a real maintainer's identity suggest the attacker held valid credentials or a signing key. The code went in by direct file upload, which bypasses the normal review a pull request would trigger.
That matters for anyone who publishes packages, including internal ones. Protect publishing rights with hardware-backed multi-factor authentication. Require review for changes to release scripts. Limit who can bump a version and trigger a publish, and alert when a release happens outside normal hours.
Consumers can add a check of their own. A new release from a package you depend on that appears right after unusual repository activity deserves a delay. Waiting a day for most dependency updates costs little, and it would have avoided this one entirely for teams that pinned versions.
Aikido's own timeline also shows how quickly detection can work. Socket flagged the release 11 minutes after publication. The gap between flagging and your install is the part you control, which is why automated scanning at install time, not only in a weekly report, is worth the setup.
What Should Your Team Practice Before the Next One?
Rehearse the response before you need it. Pick a pretend compromised package and run the checks above on a test project. Time how long it takes to list affected builds and to rotate a key.
Write the steps into your runbook. Our guide to building an incident response runbook shows a format that on-call engineers will actually follow. Include the warning about token revocation order in bold at the top.
Our read at Backtrace is that the dead-man's switch changes the calculus. Fast revocation used to be the safest move. Against this family of malware, it can make things worse, so the first step is containment and a calm look at what is running.
Conclusion
The Tensorlake compromise was caught in minutes and removed quickly, but any machine that installed 0.5.144 should be treated as breached. Check lockfiles and logs, contain and rebuild, then rotate secrets in the right order. Blocking install scripts by default is the single best change you can make this week.
Start with one search: find every repository and CI job that resolved tensorlake on or after October 8. Backtrace will keep covering supply chain incidents as they develop.
