A poisoned npm release: what one postinstall can carry away

Installing a dependency means installing the publisher’s account security along with it. On 7 October, version 0.5.144 of the TypeScript SDK tensorlake was confirmed to carry the Shai-Hulud credential-stealing worm. Version 0.5.143 and earlier were reported clean.

The timeline

StepSecurity’s write-up gives unusually precise coordinates: the first malicious commit landed on the main branch of tensorlakeai/tensorlake at 01:20 UTC on 2026-10-07, under a maintainer’s name. Seven more commits followed over the next few hours, adjusting the payload and adding a preinstall instruction to package.json.

The tempo is the interesting part. This was not a one-shot injection; somebody was watching results and iterating. That reads like a sustained operation, not a script that got lucky.

What the payload went after

The target list covers most of a modern developer’s holdings:

• npm and GitHub tokens
• cloud keys
• SSH keys
• Vault and Kubernetes credentials
• browser logins
• AI tool configuration

That last item deserves a second look. Older worms cared about CI and the cloud. This one also cares about the local keys that can call a large model directly — and those have no quota alarm and no audit log, so nobody notices for a long time.

Why provenance does not help

npm provenance proves which repository and which commit a package was built from. It attests to the origin of the build, not the content of the source.

Here the entry point was the maintainer account itself. Every link in the build chain was genuine: a real repository, real commits, real CI. Supply-chain attacks stopped being about forging provenance a while ago. They are about borrowing it.

Provenance answers “who built this package”. It does not answer “is that still the same person”.

The cleanup trap

One counter-intuitive detail: the payload included a token watcher. If you revoke the stolen GitHub token before removing the watcher, the watcher can wipe the home directory.

In other words, the standard emergency reflex — revoke credentials first — is what triggers data loss here. That does not mean don’t revoke. It means the order of cleanup depends on intelligence about the malware, not on muscle memory.

My take

For a personal project I am not going to build an elaborate supply-chain defence. Three things actually fit:

1. Commit the lockfile and read its diff — an extra preinstall in package-lock.json is visible.
2. Don’t keep long-lived cloud credentials on a development machine; use short-lived tokens where you can.
3. When installing something new, npm install --ignore-scripts blocks this entire class.

The third has a real cost: some packages genuinely need a build step, and ignoring scripts breaks them. But “it failed to install” is a problem you find immediately. “It installed and got robbed” is not.