What happened inside the Tensorlake repository
On October 7, at 01:20 UTC, a rogue commit landed on the main branch of the tensorlakeai/tensorlake repository, appearing under a legitimate maintainer's name according to analysis from StepSecurity. Roughly a day later, the repository's own automated release workflow published version 0.5.144 of the tensorlake npm package, a TypeScript SDK used to build Tensorlake applications and sandboxes. The release has since been pulled from the registry, but not before it reached anyone who ran an install during that window. A GitHub issue on the tensorlake repository, filed as issue number 1014, documents the compromise publicly, though the article does not identify who first flagged it.
The mechanism is what makes this more than a routine compromised package. Researchers at Socket and StepSecurity tie it to the ChainDrop campaign, first documented in early August and already linked to hundreds of npm packages including Keyv and Cacheable, now running a payload the security community calls Shai-Hulud. The malicious release carries a preinstall hook that runs a file called package/lib/setup.mjs, which launches an obfuscated loader. That loader in turn executes the main payload, package/lib/Math_Symbol.js, via the Bun runtime, and drops a credential-harvesting binary called HackBrowserData alongside its own worm logic.
Why this worm specifically wants your AI tooling
Credential-stealing npm malware is not new. What distinguishes this payload is its target list: npm, GitHub, and AWS credentials, HashiCorp Vault and Kubernetes secrets, SSH keys, .env files, cryptocurrency wallets, messaging app data, and configuration files for Claude, Cursor, Kiro, Windsurf, and Zed. That last category is the tell. As engineering teams wire AI coding assistants directly into repositories with broad read and write access, those tools' local configs have become a credential and persistence target in their own right, not an afterthought.
StepSecurity found the malware writes .claude/settings.json and .vscode/tasks.json into any reachable repository, so the payload re-executes the moment a developer opens that project in Claude Code or VS Code. Combined with a propagation routine that enumerates packages tied to the victim's own publishing identity, builds Sigstore provenance for them, and republishes compromised versions under the victim's name, this worm is designed to spread through exactly the developer workflows that AI coding tools have made faster and more automated.
The hostage-token problem
The standard first response to a credential-stealing worm is to revoke the exposed tokens immediately. This payload complicates that instinct. A PowerShell monitor it installs repeatedly polls the GitHub API endpoint api.github.com/user using the stolen token, and if that token is revoked, the monitor executes an attacker-supplied handler through Invoke-Expression, which researchers believe is designed to trigger a destructive routine against the victim's own repositories or systems. The malware also stages encrypted stolen data in a public GitHub repository it creates, titled by its operators Shai-Hulud: Here We Go Again, a direct continuation of the campaign's naming from its earlier wave. Command and control resolution for the malware runs through an Ethereum smart contract that points to the domain iseekaigogo[.]com, with GitHub itself serving as a fallback channel.
That design forces incident response teams into a harder sequencing decision than usual. Revoking a compromised token is normally step one of any breach response, done without hesitation. Here, teams need to isolate the affected systems and capture forensic state before revocation, because the act of cutting off access may itself trigger the next stage of the attack. Any runbook written before this disclosure should be revisited with that sequencing risk in mind, for this incident and for whatever variant comes next.
What this means for dependency risk, not just incident response
The repository compromise, not a stolen npm publish token alone, is what let a well-known SDK ship a backdoored release through its own legitimate build pipeline. That is a reminder that supply-chain risk now lives upstream of the registry, in repository access controls, branch protection, and release workflow permissions. A package with no history of compromise and a maintained GitHub presence passed every reasonable trust signal right up until the moment someone else's commit reached main and the existing CI pipeline did exactly what it was built to do.
Teams that gate dependency updates on npm reputation scores, download counts, or maintainer activity should treat this as evidence that those signals do not catch a compromised release fast enough. A one-day gap between commit and publish leaves almost no room for manual review. The practical mitigation is automated: pin dependency versions rather than tracking latest, require a delay window before new releases are auto-pulled into CI, and monitor for exactly the kind of local config writes this worm performs, regardless of which package triggers them.
The roadmap takeaway
Any organization that installed tensorlake 0.5.144 needs to treat this as a full compromise, not a package removal. That means rotating npm, GitHub, AWS, Vault, and Kubernetes credentials, rechecking SSH keys and cloud wallet access, and auditing every repository the affected developer could reach for planted GitHub Actions workflows disguised as Copilot or Dependabot automation, or the .claude and .vscode persistence files StepSecurity identified, before revoking the GitHub token that the hostage-token routine is watching. Teams should also check whether any of their own packages were republished through the victim's publishing identity and Sigstore provenance, since the worm's propagation step is designed to make that republishing look legitimate.
For everyone else, the broader lesson is about where AI coding tools now sit in the attack surface. A credential stealer that specifically targets Claude Code, Cursor, Kiro, Windsurf, and Zed configuration is a signal that attackers see AI-assisted development workflows as a reliable persistence mechanism, not a curiosity. Any security review of AI tool adoption that still treats the models as the risk and the surrounding developer tooling as incidental is reviewing the wrong half of the stack.
