On October 8, 2026, the Tensorlake SDK was compromised. This package has 18k downloads/week and the attack shares a lot in common with the August compromise of the "cacheable" and "keyv" packages. If anything in your organization installed Tensorlake SDK 0.5.144 on or after October 8, 2026, treat the npm, GitHub, and cloud credentials on that machine as compromised, along with any AI coding tool configs. The malicious version ran a credential-stealing worm on install. Here’s how to check whether you’re affected, what to rotate, and how Cloudsmith helps keep versions like this out of your builds.
On October 8, an attacker published version 0.5.144 of the Tensorlake SDK, a package with about 18,000 weekly downloads. It contained two files that work together:
setup.mjs runs through a preinstall hook and launches the payload using Bun.The worm exfiltrates npm and GitHub tokens, cloud credentials, and AI coding tool configuration files. It also establishes persistence, so attackers keep access after you remove the package. One infected install can give an attacker the keys to your pipelines and your AI agents at the same time.
Jenn Gile of Open Source Malware pointed out that this attack closely resembles the August compromise of the cacheable and keyv packages. Both are npm worms built on the mini Shai-Hulud code TeamPCP open-sourced this spring, and both use the same two-file pattern. There’s no evidence yet that the same group is behind both. The Hacker News reports that the attack shows attackers are now going after the AI tools developers rely on.
Two questions determine your exposure: did you install 0.5.144, and could its preinstall script run?
Review Project Lockfiles. Compare the packages and versions in your lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) and installed node_modules against the affected version number.
Match on whole package names, not substrings. When scripting your own checks, anchor on exact package names. Loose substring matching produces false positives (for example, flagging an unrelated package that merely contains an affected name as a fragment) and wastes triage time.
Check whether preinstall scripts can execute. Determine your npm client version and whether lifecycle scripts are enabled in your environments. If you are on npm 12+ with scripts disabled by default, an affected version that was pulled but never executed represents materially lower risk.
Rotate credentials if it ran. If 0.5.144 could have run on a developer machine or CI runners, remove it. Then rotate npm tokens, cloud credentials and any secrets reachable from that environment, and review recent publish activity on your own packages.
Check Cloudsmith client and package logs. Review your Cloudsmith client logs and the package’s download logs to see whether 0.5.144 was requested or pulled. Client logs show which environments attempted to resolve the package. Package logs show whether the version entered your repository cache and which identities or pipelines downloaded it.
Search Cloudsmith and quarantine. Without a cooldown or malware policy, a developer or pipeline may have pulled 0.5.144 into your Cloudsmith cache. Search for it and quarantine any copies.
Old, dormant projects with pinned references are usually low risk, because a locked dependency tree keeps the version it already has. The exposure comes from a fresh install or a lockfile refresh that resolved to 0.5.144.
Public registries supply most of your dependencies, and they serve the ecosystem well, but pulling from them straight into builds also means a malicious version can reach you minutes after it’s published. Cloudsmith sits between the public registry and your developers and pipelines as one policy-enforced control point. Two popular policies at Cloudsmith are cooldown policies and malicious package policies, which work hand in hand. Cooldowns handle the versions nobody has vetted yet. Malicious package policies take over once a version is known to be malicious.
Cooldown Policies. Many package managers have client-side cooldowns built in, but they can be difficult to manage at scale for enterprises. Cloudsmith enforces the cooldown at the registry, whatever the client version or script settings, by holding back newly published upstream versions for a defined window before they become installable. Attacks like this one depend on speed: a malicious version is published, pulled into builds within minutes or hours, then withdrawn. A cooldown policy keeps those versions away from your teams during the window when they are most dangerous, giving the ecosystem time to flag them.
Malicious package policies. When the community does flag a version, malicious package policies act on it. Packages flowing through Cloudsmith are scanned for malware and matched against our database of malware advisories. With policy management from Cloudsmith, you can block versions flagged as malicious or matching known indicators. Once a package is identified as compromised, the policy stops it from reaching any consumer behind Cloudsmith, including after the cooldown window ends, and no developer has to update a manual blocklist.
A single source of truth. When installs resolve through Cloudsmith, you get one place to enforce controls and one audit trail of what entered your environment. “Were we exposed?” becomes a search of your own records, rather than reconstructing it across every machine and pipeline. Policies only cover traffic that routes through them, so the practical first step is making sure your installs go through Cloudsmith instead of going straight to public registries.
With these controls in place, you can answer the next npm worm with one search of your Cloudsmith records.
