TL;DR: A popular coding package became a trap this week, and the trap springs the moment you try to stop it. Researchers found that a poisoned version of the Tensorlake package on npm steals a developer’s secrets as soon as it installs. Revoke the login token it stole, and a hidden job on your machine wipes your home directory.
What Happened?
The part that should scare every engineering team: the package carried a valid build signature, so the tools that trust that signature waved it through.
The bad code was pushed to the project’s main branch under a maintainer’s name, with no review, then published to npm from the same repo. That is why npm showed a provenance badge. A provenance badge only says where a package was built. It says nothing about whether the code is safe.
On install, a preinstall step fires. It skips automated build servers and targets real developer laptops. It pulls down a separate runtime to run a scrambled payload that researchers decoded without running.
What’s the Impact?
What does it grab? GitHub and npm tokens, cloud keys, SSH keys, secrets from popular secret managers, saved browser passwords, and the config files for AI coding tools. The loot gets pushed to a new public repo in the victim’s own account, or shipped to an attacker-controlled domain.
Then it spreads. With a stolen npm token, it republishes the victim’s other packages with itself inside. With a stolen GitHub token, it drops hidden files into their repos, so it runs again the next time someone opens the project in a code editor or AI assistant. This is a self-spreading worm on its second wave.
Now the nasty bit. The code installs a watcher that checks the stolen token every 60 seconds for up to a day. The instant that token stops working, the watcher deletes your entire home directory. So the first move most people make after a breach, revoking the token, is the one that sets off the bomb.
One careless install can leak every key a developer touches, expose your private code, and poison the packages your own customers pull next.
IOCs (Indicators of Compromise)
Hunt for these on your machines and in your repos
Source and caveat: indicators are from researchers’ analysis of this package within the wider self spreading worm wave. Current as of October 8, 2026 and may expand as the worm republishes other packages. Treat an empty result with caution: an attacker with your tokens can plant fresh copies elsewhere.
How to Avoid This
How do you keep from getting burned?
- Pin the package to the last clean version, delete your installed modules, and clear your package cache.
- Turn off install scripts so hooks like this cannot fire on their own.
- If the bad version ever touched a machine, find and remove the watcher first.
- Only then revoke tokens and rotate every other key it could reach.
- Hunt your account for new public repos and commits you did not make.
- If you cannot be sure a machine is clean, wipe it and start fresh.
A Green Check Mark Is Not a Clean Bill of Health
A signed package is not a safe package, and a green check mark is not a clean bill of health. The install itself is now part of your attack surface, and the only real answer is proof that what your developers pull in is not already working against them.
- A Red Teammate looks at your pipeline the way an attacker would, flagging risky dependencies and exposed secrets before a worm does.
- A SOC Teammate watches for the quiet tells, like a strange new repo in your org or commits from an author nobody recognizes.
- An AppSec Teammate holds a release gate on new package versions, so a fresh, unproven release doesn’t sail into production.
- Every containment step waits for your team’s approval and lands in a full audit trail, so the software does the legwork while people keep control.
- It runs above the stack you already own, so you don’t have to rip anything out.