Tensorlake npm Package Compromised: Anatomy of the Shai-Hulud Worm, Hostage Token Wipe-Switch, and AI Supply Chain Attacks

The CyberSec Guru

Tensorlake npm Package Compromised

If you like this post, then please share it:

Buy me A Coffee!

Support The CyberSec Guru’s Mission

🔐 Fuel the cybersecurity crusade by buying me a coffee! Why your support matters: Zero paywalls: Keep the main content 100% free for learners worldwide.

“Your coffee keeps the servers running and the knowledge flowing in our fight against cybercrime.”☕ Support My Work

Buy Me a Coffee Button

On October 8, 2026, security researchers identified a compromise of Tensorlake, a serverless sandbox platform with a TypeScript SDK for AI agents. Version 0.5.144 on npm carried a new variant of the Shai-Hulud worm, an evolution of the ChainDrop attacks that hit the npm ecosystem earlier this year.

The package has more than 100,000 lifetime installs and about 12,000 weekly downloads, so the exposure reaches enterprise CI/CD pipelines, cloud infrastructure, and local developer workstations. The attackers did more than steal credentials. They abused cryptographic provenance, used Ethereum as a command-and-control (C2) fallback, wrote persistence into the configuration files of AI coding tools, and added a “hostage token” that wipes the victim’s machine if responders revoke the stolen GitHub token the way standard playbooks tell them to.

The short version for responders: isolate the host first, rotate credentials later. The details follow.

The initial breach and the Sigstore provenance problem

Attacks like this usually start with a stolen identity rather than a bug in the package manager. According to telemetry analyzed by StepSecurity and Aikido, the intrusion began on October 7, 2026, at 01:20 UTC. The attackers took over a verified maintainer’s GitHub identity, got past the usual authentication controls, and pushed a malicious commit (41b38f0) directly to the main branch of tensorlakeai/tensorlake. The commit added heavily obfuscated JavaScript files to the source tree. The repository stayed in that state for about 20 hours, until the project’s automated release workflow built the code and published 0.5.144 to the public npm registry.

Valid provenance on a malicious build

The release was built inside the project’s own GitHub Actions environment and published with a valid npm provenance attestation through Sigstore. Provenance proves where a package was built. It does not tell you what the code does once the maintainer account or the repository is under attacker control. Here the attacker controlled both, so the pipeline built the malware, signed it with a valid Sigstore certificate, and published it. A scanner that trusts provenance alone would likely have marked tensorlake@0.5.144 as trusted, and the package could have passed the ingestion checks in artifact repositories such as JFrog Artifactory or Sonatype Nexus.

The execution chain: Bun as an EDR blind spot

The infection starts when a developer or a CI/CD runner runs npm install on a project that depends on the compromised version.

The preinstall hook and the stage-one dropper

The package defines a preinstall script in package.json that runs node lib/setup.mjs before the package is unpacked or imported. It executes whether or not the project ever uses the Tensorlake library. setup.mjs is heavily obfuscated and acts as a stage-one dropper. It does not steal data itself. It downloads the Bun JavaScript runtime and uses it to set up a separate execution environment.

Why Bun

Using Bun is a deliberate evasion choice. Enterprise security stacks watch node.exe closely. Teams have behavioral baselines for it, and EDR tools scrutinize it for odd child processes, suspicious command-line arguments, and unauthorized network connections. Bun is popular with developers but still new to many enterprises, so EDR and application control profiles often lack mature, restrictive rules for bun.exe.

The dropper puts a legitimate runtime in a temporary directory and uses it to run the second-stage payload, lib/Math_Symbol.js. That moves execution out of the monitored node.exe process tree and past script-focused heuristics tuned for Node.js anomalies. It is a living-off-the-land technique applied to developer tooling.

The payload: stealing secrets and targeting AI workspaces

Once Bun runs lib/Math_Symbol.js, the Shai-Hulud payload starts. The ChainDrop attacks of August 2026 went after generic web packages. This variant goes after tooling used by AI developers.

📬 Stay Ahead of Cyber Threats

Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.

Subscribe to the Newsletter →

Credential and cryptocurrency harvesting

The malware enumerates the host for secrets right away. It drops the HackBrowserData binary to decrypt and extract browser profiles, focusing on cryptocurrency wallet extensions (MetaMask, Phantom, Coinbase Wallet, Rabby, Trust Wallet, and Solflare) and messaging app databases.

It also scrapes the file system and environment variables for AWS access keys, Azure configurations, and GCP service account JSON files; Kubernetes kubeconfig files, Docker credentials, HashiCorp Vault tokens, and SSH private keys; and GitHub personal access tokens (PATs) and npm authentication tokens stored in .npmrc files.

Poisoning the developer’s AI tools

This variant searches for and modifies configuration files for Cursor, Claude Code, Windsurf, Kiro, and Zed. Writing to .vscode/tasks.json and .claude/settings.json gives it persistence in two ways.

The first is VS Code tasks. The malware injects hidden tasks into .vscode/tasks.json that run automatically when the workspace opens or when certain build commands fire. It re-executes every time the developer opens the IDE, with no need to touch OS-level persistence such as the Registry or Scheduled Tasks.

The second is the AI agent itself. By changing the settings of agents like Claude Code, the attacker can alter the agent’s system prompts, allowed tool lists, or execution permissions. When the developer then asks the agent to write code, debug an issue, or read local files, it could be silently told to exfiltrate sensitive context or run arbitrary shell commands. That skips the traditional malware execution chain entirely.

Command and control: a blockchain fallback

Hardcoded C2 domains get identified, sinkholed, and blocked quickly, so the worm carries a blockchain fallback. The primary C2 is hardcoded: iseekaigogo[.]com. If that fails, the malware queries a public Ethereum RPC endpoint and reads from an actor-controlled smart contract (0xb614155Fd88114d40549b259457Bcf921Df091B9).

The contract works as a dead drop. If enterprise firewalls block the domain or a security vendor sinkholes it, the actor updates the contract with a new C2 IP address or domain, and the malware follows without a new npm release. Because the data sits on a public blockchain, static network blocking does little. Ransomware and botnet operations have used the same technique before.

If both the domain and the blockchain lookup fail, the malware falls back to public GitHub repositories, searching for ones named “Shai-Hulud: Here We Go Again” as a staging ground for encrypted stolen data. That traffic blends in with legitimate developer API calls.

The hostage token and destructive anti-forensics

This is the most dangerous feature, and it forces a rewrite of standard incident response (IR) playbooks. It works as a destructive dead-man’s switch.

The trap for responders

When a security operations center (SOC) finds a compromised GitHub or npm credential, the standard move is to log into the console and revoke the token to cut off the attacker. The payload expects that. After it runs, it extracts the developer’s GitHub token and starts a background PowerShell monitor that polls api.github.com/user with the stolen token. A 200 OK means the token is still valid, and the malware keeps working quietly. A 401 Unauthorized means someone revoked it, and the monitor runs a destructive payload through the Invoke-Expression cmdlet. That payload is built to wipe the machine quickly, delete local source code repositories, corrupt the .git directory, and destroy forensic artifacts.

An analyst who follows the usual playbook and revokes the token from a central dashboard before isolating the host will trigger that sequence. The result is lost evidence and possibly serious disruption to the developer’s local environment.

My advice is to treat any workstation or CI/CD runner that installed tensorlake@0.5.144 as compromised and hostile, and not to revoke credentials right away. Isolate the host at the network level first, through EDR quarantine or by disconnecting it from the switch, so it cannot reach the GitHub API. Capture volatile memory next. Rotate the credentials only after that, from a clean, out-of-band system.

Worm propagation

Shai-Hulud is also a self-propagating worm. After it harvests the victim’s npm publishing tokens and GitHub credentials, it starts spreading.

Republishing with fresh attestations

Using the stolen npm tokens, the worm enumerates every other package tied to the victim’s publishing identity. It injects the payload into their source, builds a new Sigstore provenance attestation (the same trust mechanism abused in the Tensorlake compromise), and republishes the compromised versions to npm. That spreads the infection across the organization’s packages and into downstream applications that depend on them.

Fake Dependabot and Copilot workflows

To get malicious code merged into other repositories, the malware targets GitHub Actions. It scans open pull requests and automated workflows and injects strings that reference fake Copilot or Dependabot operations. The goal is for code planted in what looks like an automated dependency update or an AI-generated suggestion to be approved and merged by downstream maintainers, which puts the infection into production codebases.

Incident response and mitigation

Remediation takes coordination between DevOps, Security Engineering, and the SOC.

containment and isolation (do not revoke tokens yet)

  1. Query your Software Bill of Materials (SBOM) and artifact repository logs to find every workstation, CI/CD runner, and server that installed tensorlake@0.5.144.
  2. Isolate those hosts at the network level through your EDR or network access control (NAC). Do not power them off. That destroys the volatile memory you need for forensics and may trigger the anti-forensic mechanisms if not handled correctly.
  3. Block the C2 domain iseekaigogo[.]com at the DNS, proxy, and firewall layers. If your infrastructure supports blockchain traffic filtering, add deep packet inspection (DPI) or proxy rules to block outbound traffic to the Ethereum smart contract addresses.

forensics and evidence collection

  1. From the isolated host, capture a full memory dump to analyze the Bun execution and recover any unencrypted secrets still in memory.
  2. Image the disk to preserve .claude/settings.json, .vscode/tasks.json, and any modified local repositories before the hostage token can trigger a wipe.

credential rotation and eradication

  1. From a known-clean system, rotate every credential tied to the compromised developer or CI/CD runner:
    • npm publishing tokens and .npmrc authentication
    • GitHub PATs and SSH keys
    • AWS, Azure, and GCP access keys
    • HashiCorp Vault tokens and Kubernetes kubeconfig files
    • Cryptocurrency wallet seed phrases, if they were stored locally or the wallet was accessed
  2. Remove tensorlake@0.5.144 from all package.json, package-lock.json, and yarn.lock files, and pin dependencies to known-good, verified versions.
  3. Inspect local and repository-level .vscode/tasks.json and .claude/settings.json files by hand for unauthorized changes, hidden tasks, or altered AI agent system prompts.
  4. Review GitHub Actions logs and recent pull requests across all organizational repositories for unauthorized commits, fake Dependabot updates, or injected workflows from the compromised identity.

long-term hardening

  1. Move CI/CD pipelines off long-lived PATs and static API keys. Use OpenID Connect (OIDC) to issue short-lived, scoped tokens for GitHub Actions and cloud providers.
  2. Do not rely on Sigstore attestations alone. Add runtime application self-protection (RASP) and behavioral analysis to your CI/CD pipelines so that anomalous script execution during npm install, such as a download of the Bun runtime, gets flagged.
  3. Require FIDO2/WebAuthn hardware security keys for all npm maintainers and GitHub organization administrators to block phishing and session hijacking.

Indicators of compromise (IoCs)

Ingest these into your SIEM, EDR, and threat intelligence platforms. IP addresses and domains are defanged with [.] to prevent accidental resolution or hyperlinking. Re-fang them only inside controlled threat intelligence environments.

TypeIndicatorDescription
Compromised packagetensorlake@0.5.144Malicious Tensorlake version published to the npm registry.
C2 domainiseekaigogo[.]comHardcoded primary control and exfiltration destination.
Malicious filelib/setup.mjsObfuscated preinstall-stage loader that downloads and launches Bun.
SHA-256 hash25a0735d0db7dc40e5d45ce42d9c106067e6a66e184d967cfecfab17c3bcb5efHash of the lib/setup.mjs dropper.
Malicious filelib/Math_Symbol.jsObfuscated Shai-Hulud payload executed through the Bun runtime.
SHA-256 hashb50a00900399ba99fb6ce1fc151519cb99d44320ef2a631f2237e1aea0ad6fecHash of the lib/Math_Symbol.js core payload.
Ethereum contract0xb614155Fd88114d40549b259457Bcf921Df091B9Actor-controlled contract queried for alternate C2 destinations.
Ethereum wallet0x779f83aE56309682beDb04816c19d358c4B21040Wallet associated with the contract update and infrastructure funding.
Repository commit41b38f0Initial commit where the malware was introduced through a direct file upload.
Execution commandnode lib/setup.mjsPreinstall command that starts the malicious execution chain.
Targeted files.claude/settings.json, .vscode/tasks.jsonConfiguration files modified for AI agent manipulation and persistence.

Conclusion

The attackers got in through the tools meant to speed engineering up: AI coding assistants, automated CI/CD pipelines, and cryptographic provenance. A valid Sigstore attestation did not make the package safe, a Bun download slipped past monitoring built around Node.js, and a routine token revocation could have wiped the evidence. Basic dependency scanning and simple provenance checks would not have stopped this. Defending against it takes zero-trust CI/CD, short-lived identity federation, and behavioral monitoring of developer workspaces.

Buy me A Coffee!

Support The CyberSec Guru’s Mission

🔐 Fuel the cybersecurity crusade by buying me a coffee! Your contribution powers free tutorials, hands-on labs, and security resources.

Why your support matters:
  • Writeup Access: Get complete writeup access within 12 hours
  • Zero paywalls: Keep the main content 100% free for learners worldwide

Perks for one-time supporters:
☕️ $5: Shoutout in Buy Me a Coffee
🛡️ $8: Fast-track Access to Live Webinars
💻 $10: Vote on future tutorial topics + exclusive AMA access

“Your coffee keeps the servers running and the knowledge flowing in our fight against cybercrime.”☕ Support My Work

Buy Me a Coffee Button

If you like this post, then please share it:

News

Discover more from The CyberSec Guru

Subscribe to get the latest posts sent to your email!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from The CyberSec Guru

Subscribe now to keep reading and get access to the full archive.

Continue reading