Supply Chain Attack Through Tensorlake npm Package Steals Credentials and Spreads Malware

Cybersecurity researchers disclosed that version 0.5.144 of the tensorlake package on npm was compromised with malware tied to a supply chain campaign linked to ChainDrop/Shai-Hulud. This malware executes during package installation via a preinstall script and is designed to steal credentials and sensitive information from developer systems, including tokens for npm, GitHub, AWS, Kubernetes, HashiCorp Vault, SSH keys, .env files, and data related to AI development tools.
Following the discovery, version 0.5.144 of the package was removed from npm. The malware actively collects and exfiltrates data from infected systems and uses stolen npm tokens to publish additional packages under victims’ accounts, facilitating further spread through the software supply chain. Additionally, malicious files were created in .claude and .vscode directories to allow malicious commands to be re-executed upon project opening via Claude Code or Visual Studio Code. A mechanism was implemented to continuously monitor GitHub tokens; researchers cautioned that revoking a token before removing this monitoring mechanism could trigger destructive commands on the system.
Developers who installed tensorlake@0.5.144 were advised to treat systems where the installation script ran as potentially compromised. Remediation steps included reviewing dependencies, lockfiles, and build logs, stopping use of the affected version in favor of a trusted release like 0.5.143, and ensuring GitHub tokens were not revoked prematurely. Following containment, organizations should rotate exposed credentials and audit npm, GitHub, and cloud service accounts for unauthorized activity.

* Version 0.5.144 of the tensorlake package on npm was compromised with malware related to a supply chain campaign linked to ChainDrop/Shai-Hulud.
* The malware executes during package installation via a preinstall script.
* The malware is designed to steal credentials and sensitive information from developer systems, including npm and GitHub tokens, AWS credentials, Kubernetes and HashiCorp Vault credentials, SSH keys, .env files, and data associated with AI development tools.
* Version 0.5.144 of the package was removed from npm following discovery.
* The malware collects and exfiltrates data from infected systems.
* Stolen npm tokens are used to modify and publish additional packages under victims’ accounts to spread the compromise.
* Malicious files were created in the .claude and .vscode directories for command execution upon opening projects via Claude Code or Visual Studio Code.
* The malware includes a mechanism that continuously monitors stolen GitHub tokens.
* Revoking a GitHub token before removing the monitoring mechanism could trigger commands capable of deleting or damaging data on the system.
* Developers should revert to version 0.5.143 for investigation and remediation.

The event reveals a sophisticated exploitation targeting the deep trust inherent in the software supply chain, moving beyond simple vulnerability disclosure into persistent infrastructure compromise. The malware’s ability to target credentials across multiple platforms (npm, cloud providers, code editors, version control) suggests an intent not just for data theft but for lateral movement and account takeover within developer environments. The use of specific artifacts like `.claude` and `.vscode` directories points toward embedding persistence mechanisms directly into the developer workflow, effectively turning trusted coding environments into potential vectors for malicious command execution.
The warning regarding GitHub tokens highlights a critical tension: remediation actions themselves can trigger destructive consequences if executed improperly. This creates a decision point where necessary security actions clash with operational recovery—the need to immediately stop exfiltration versus the risk of triggering unintended data loss through system manipulation. Furthermore, the specific mechanism for spreading (using stolen npm tokens for publication) confirms that the compromise is designed to leverage existing permissions for ongoing malicious activity rather than being a one-time breach.
The pattern suggests an adversary focused on deep entanglement: compromising the package layer, exploiting the execution environment, and weaponizing identity tokens across the entire development stack. The implication for agency is the increased cognitive load required for remediation, forcing developers to manage not just code security but also the integrity of their operational secrets.
BRIDGE QUESTIONS: If systems are compromised by an installation script, what independent verification methods can developers establish to confirm that post-installation changes have not occurred? What oversight mechanisms should exist outside of package registries to monitor and flag suspicious activity within developer sandboxes? How can security practices be developed to safely manage high-stakes response actions, such as token revocation, when destructive commands are a known risk?