The TensorLake npm Compromise: Why AI Coding Tool Configs Are Now a Supply Chain Target

The technical novelty here is not the existence of another npm worm, this is at least the third disclosed Shai-Hulud family attack this year, it is the dead man's switch. Most credential stealing malware tries to avoid detection and exfiltrate quietly. This one assumes you will eventually find and revoke the stolen token, and plants a persistence mechanism specifically designed to punish that response: a scheduled task that polls the GitHub API with the stolen token, and if the token stops working, executes an attacker supplied command that can wipe the user's home directory. That inverts the standard incident response instinct of revoke first, investigate second, and it is the single detail from this disclosure every engineering team running npm installs should internalize before their next credential rotation.

Why install time execution matters more than the payload itself

The malware runs through a preinstall hook, meaning the malicious code executes during npm install itself, before any application code imports the compromised package. This is a distinction worth being precise about internally: a vulnerability in code you call is something you can mitigate by not calling the vulnerable function, a vulnerability in code that runs automatically during installation is something you can only mitigate by not installing the compromised version in the first place, or by running installs in an environment where a compromised preinstall script has nothing valuable to steal. If your CI pipeline runs npm install with the same credentials and secret access as your production deployment step, every preinstall hook in your dependency tree, not just the ones you have audited, has that same access for the duration of the install.

The Sigstore and Ethereum details show real attacker sophistication

Two mechanisms in this attack are worth understanding beyond the headline. First, propagation: the worm enumerates packages linked to the victim's publishing identity, builds Sigstore provenance attestations, and republishes compromised versions under that trusted identity. Sigstore exists specifically to let consumers verify a package's build provenance, and using a compromised maintainer's own credentials to generate valid Sigstore attestations for malicious code is a direct attack on the trust mechanism meant to prevent exactly this kind of supply chain compromise. Second, command and control: rather than a hardcoded domain that defenders can blocklist, the payload resolves its endpoint by querying an Ethereum smart contract across roughly 30 public RPC endpoints, falling back to GitHub if that fails. A blockchain backed C2 resolution mechanism is materially harder to take down than a domain, since there is no single registrar or host to request a takedown from.

Why AI tool configs specifically are now in scope

The detail distinguishing this from earlier Shai-Hulud family disclosures is the explicit targeting of configuration and MCP files tied to Claude, Cursor, Kiro, Windsurf, and Zed. We have covered the broader pattern of AI agent memory systems becoming a supply chain target earlier this month, and this is a related but distinct escalation: that disclosure involved a worm targeting the memory layer of AI agent frameworks, while this one targets the developer tooling configuration layer directly, the API keys, MCP server definitions, and local settings that an AI coding assistant stores to do its job. As more engineering teams grant their coding agents direct access to cloud credentials, deployment tooling, and internal APIs through MCP servers, those configuration files increasingly hold exactly the kind of high value secrets that used to live only in a password manager or a cloud provider's own secrets store. Attackers targeting them specifically, rather than picking them up incidentally alongside SSH keys and npm tokens, is the natural next step once that value becomes obvious, and it will not be the last disclosure to do so.

The remediation sequence that actually matters

Socket's published guidance includes a step that is easy to skip under pressure and is the single most important one given the dead man's switch described above: remove the persistence monitor before revoking any stolen token, not after. On Linux that means disabling the gh-token-monitor service and deleting its config directory; on macOS, unloading the LaunchAgent; on Windows, deleting the scheduled task running the monitor script. Only once that monitor is confirmed removed should credentials actually be revoked and replaced, followed by an audit of connected accounts for unauthorized publications or repository changes, and a rebuild of any affected environment from trusted sources rather than trusting that removing the package alone removed the implant.

What this means for how you configure AI coding agents

The practical takeaway for any team using Claude Code, Cursor, or similar tools with MCP servers connected to real infrastructure is to treat those configuration files with the same handling discipline you already apply to cloud credentials and CI secrets, not as local developer convenience files. That means not committing MCP configuration files to source control even in private repositories, scoping the credentials any MCP server can reach to the minimum the specific integration needs rather than a broad service account, and treating a compromised developer workstation as a potential path to whatever your AI coding tools are configured to reach, not just to your source code.

When this applies to your stack

If your team uses npm in any CI pipeline with access to production or near production credentials, verify that preinstall and postinstall scripts are either disabled by default or run in an isolated environment without access to those credentials, since that is the actual blast radius this attack class depends on. If your developers use AI coding tools with MCP servers configured against real cloud or internal API access, audit what those configuration files currently contain and whether the credentials inside them are scoped tightly enough that a compromised workstation would not hand an attacker broad infrastructure access. Building that credential isolation into your development environment before an incident forces the audit is the kind of infrastructure security work we help engineering teams get ahead of.

FAQ

What should I do if I installed tensorlake version 0.5.144? Treat the host as compromised. Remove the persistence monitor first (the scheduled task or service polling your GitHub token), only then revoke and replace exposed credentials, audit connected accounts for unauthorized changes, and rebuild the environment from trusted sources rather than just removing the package.

Why does this attack specifically target AI coding tool configuration files? As MCP servers give AI coding agents direct access to cloud credentials and internal APIs, the configuration files storing those connections hold increasingly high value secrets, similar to a cloud provider's credentials file. Attackers targeting them specifically reflects that growing value.

Is this the same attack as the earlier AI agent memory supply chain worm? No, though it is related. That disclosure targeted the memory layer of AI agent frameworks specifically. This one targets developer tooling configuration broadly, including but not limited to AI coding assistants, alongside standard npm tokens, cloud credentials, and SSH keys.

What makes this attack's persistence mechanism unusual? A scheduled task polls the stolen GitHub token's validity, and if the token is revoked while that monitor is still running, it can execute an attacker supplied command capable of wiping the user's home directory. Removing the monitor before revoking tokens is the critical, easy to miss remediation step.