The Challenge
On October 7, 2026, a maintainer account for the tensorlake repository pushed malicious code to the main branch. Within 24 hours, the repository's automated release workflow published version 0.5.144 to npm, embedding a credential-stealing worm into a TypeScript SDK used for AI application development and cloud services.
The malicious package contained obfuscated malware designed to harvest credentials across local files, CI environments, Kubernetes clusters, and Vault sources. It targeted npm tokens, GitHub credentials, AWS secrets, SSH keys, .env files, cryptocurrency wallets, and configuration files for AI development tools including Anthropic Claude, Cursor, and Windsurf. The worm didn't just steal; it propagated itself by enumerating packages associated with the victim's publishing identity, building Sigstore provenance, and republishing compromised versions.
This was a fully automated attack chain that turned trusted development workflows into distribution channels for malware.
Structural Weaknesses in Software Supply Chains
The attack exploited three common weaknesses:
Automated release pipelines with insufficient human checkpoints. The repository's workflow published to npm without requiring manual review of the commit that triggered the release. Once the malicious code reached the main branch, the automation treated it like any other update.
Broad credential scope in CI environments. The malware executed with access to secrets across multiple platforms, not just the immediate build environment, but Kubernetes credentials, Vault tokens, and cloud provider keys stored for deployment automation.
Trust inheritance in package ecosystems. Developers who installed tensorlake 0.5.144 inherited not just the package's functionality, but its preinstall hooks, which launched obfuscated loaders using the Bun runtime. The malware dropped the HackBrowserData binary, established persistence on the host, and executed remotely-supplied code.
The attack also demonstrated sophisticated command-and-control infrastructure. It first attempted to exfiltrate data to "iseekaigogo[.]com:443/router." If that failed, it read an Ethereum contract to resolve the command-and-control endpoint. As a fallback, it staged encrypted stolen data in public GitHub repositories with the description "Shai-Hulud: Here We Go Again."
Detection and Response
Socket detected the compromise through behavioral analysis of version 0.5.144. The package contained a preinstall hook launching "package/lib/setup.mjs," an obfuscated loader that executed the main worm ("package/lib/Math_Symbol.js").
StepSecurity revealed the attack timeline: malicious files pushed to the main branch under a maintainer's name, followed by automated publication through the repository's release workflow. The malware wrote .claude/settings.json and .vscode/tasks.json files into accessible repositories, ensuring it would execute again when developers opened projects in Claude Code or VS Code.
The npm registry removed version 0.5.144 from availability. Organizations that had installed it received guidance to remove the package immediately and rotate all credentials that might have been exposed.
Impact and Lessons Learned
Version 0.5.144 is no longer available for download from the npm package registry. The scope of credential exposure extended beyond single API keys; any secrets accessible to the executing process were at risk, and the persistence mechanism could retain attacker access even after teams removed the affected dependency.
The malware included a "hostage token" component that used a PowerShell monitor to repeatedly poll "api.github.com/user" with stolen GitHub tokens. If the victim revoked the token, the monitor executed attacker-supplied code designed to wipe the home directory.
Strengthening Your Defenses
Organizations affected by this compromise should implement three controls before the next package update:
Require manual approval for releases triggered by off-hours commits. The initial rogue commit occurred at 01:20 a.m. UTC. Your release automation should flag off-hours commits for review before publication.
Scope CI credentials to the minimum required for the specific build. If your deployment pipeline has access to Kubernetes credentials, Vault tokens, and AWS secrets simultaneously, you're creating a single point of compromise that spans your entire infrastructure.
Monitor for preinstall and postinstall hook additions in dependency updates. These hooks execute with the permissions of the installing user. Your package vetting process should flag any new lifecycle scripts, especially those launching external binaries or obfuscated loaders.
Takeaways for Your Team
This attack extends the ChainDrop campaign first documented in August 2026, which compromised hundreds of npm packages including Keyv and Cacheable. The tensorlake variant specifically targeted AI agent infrastructure, demonstrating how threat actors are adapting to where enterprises store valuable data.
Audit your release workflows for human checkpoints. Automated CI/CD pipelines reduce friction, but they also eliminate the moment when a human might notice that a commit doesn't match the team's normal patterns. You don't need manual approval for every merge, but you should require it for:
- Commits that modify package.json lifecycle scripts
- Releases triggered by accounts that haven't published in the last 30 days
- Any commit that adds binary executables to the package
Segment your CI credential access by job type. Your test suite doesn't need production Kubernetes credentials. Your build process doesn't need access to HashiCorp Vault. Create separate service accounts for each pipeline stage and grant only the permissions required for that specific operation.
Treat package manager hooks as executable code, not configuration. Preinstall and postinstall scripts run with your permissions. If a dependency update adds a new hook or modifies an existing one, that's a code change that requires the same review you'd apply to a pull request modifying your application logic.
The Shai-Hulud worm succeeded because it exploited trust at three levels: trust in the maintainer account, trust in the automated release process, and trust in package installation as a safe operation. Your team needs to account for all three in your third-party risk management controls.
