A malicious release of the tensorlake npm package was published as part of a supply-chain attack linked by security researchers to the Shai-Hulud and ChainDrop malware campaigns. The affected version, tensorlake@0.5.144, contained code capable of stealing developer credentials and secrets, establishing persistence and executing attacker-controlled commands.
The release is particularly notable because it was produced through Tensorlake’s legitimate npm publishing workflow and carried npm provenance. The incident shows that provenance can verify where a package was built without proving that the source code used to build it was safe.
StepSecurity found that attackers first gained control of a Tensorlake GitHub repository administrator account and pushed malicious commits directly to the project’s main branch. The subsequent npm package was then generated through the project’s normal release process rather than through an obviously fraudulent publishing path.
According to the Tensorlake incident-response pull request, the attacker used the repository’s release workflow to publish the compromised package after altering the source. The repository history recorded the malicious changes as having been made through the legitimate maintainer account.
The malicious version appeared on npm on October 8, 2026. Socket detected the package shortly after publication, reporting detection at about 01:23 UTC, roughly 11 minutes after the registry recorded the release.
The malicious code ran during installation
The compromise was designed to execute when the package was installed. A change to package.json added a preinstall hook that invoked lib/setup.mjs, allowing the attacker’s code to run during npm installation before a developer needed to use the Tensorlake SDK itself.
The loader downloaded the Bun 1.3.13 runtime and used it to execute an obfuscated payload stored in lib/Math_Symbol.js. SafeDep measured that payload at about 856 KB and found multiple layers of obfuscation and encrypted configuration.
Socket and other researchers found functionality for collecting credentials and sensitive files from developer environments. The malware searched for npm credentials, GitHub tokens, AWS credentials, Vault credentials, Kubernetes configuration and service-account tokens, SSH keys and .env files.
It also targeted configuration and data associated with several AI development tools, including Claude, Cursor, Kiro, Windsurf and Zed. Aikido found browser credential and wallet collection capabilities covering major browsers and a range of cryptocurrency wallet extensions.
The scope goes beyond credential theft. SafeDep found an applyRemoteCode function that can execute JavaScript received from the malware’s command-and-control infrastructure using eval. The researchers observed the malware polling its infrastructure at intervals of roughly 45 to 90 seconds after exfiltration.
Persistence could turn token revocation into a destructive action
The payload also installed a persistence mechanism identified as gh-token-monitor. Researchers found platform-specific persistence methods using a systemd user service on Linux, a LaunchAgent on macOS and a scheduled logon task on Windows.
StepSecurity and SafeDep found that the monitor checks whether a stolen GitHub token remains valid. Under a specific set of conditions, invalidation of the token can trigger deletion of the user’s home directory.
SafeDep’s analysis found explicit deletion commands targeting the user’s profile on Windows and home directory on Linux and macOS. The destructive watcher is conditional rather than an automatic consequence for every infected machine: SafeDep reported that the mechanism is armed for stolen GitHub tokens associated with accounts that have no organizations.
That behavior complicates incident response because simply revoking a compromised GitHub token may activate the destructive routine. Socket and StepSecurity recommended dealing with the persistence mechanism before revoking the affected token.
The attack could spread to other packages and repositories
The malware also contained mechanisms for propagation. With access to npm credentials, it could enumerate packages that a victim was authorized to publish and inject malicious code into those packages before publishing new versions.
GitHub access provided another route for spreading the compromise. Researchers found code capable of writing malicious configuration into repositories, including .claude/settings.json and .vscode/tasks.json, creating opportunities for code execution when affected projects were opened or used with development tools.
These behaviors led researchers to characterize the malware as a worm rather than a conventional single-host backdoor.
Ethereum was used to locate command infrastructure
The malware used an Ethereum-based mechanism to resolve its command-and-control infrastructure, reducing its dependence on a fixed server address. Aikido identified the Ethereum contract 0xb614155Fd88114d40549b259457Bcf921Df091B9 and a domain, iseekaigogo[.]com, associated with the malware’s command infrastructure.
Socket reported that the payload could use public Ethereum RPC endpoints to obtain its command endpoint, with GitHub available as a fallback. The technique is associated with so-called EtherHiding methods and was also observed in the earlier ChainDrop campaign.
Why valid npm provenance did not stop the attack
The Tensorlake incident highlights a specific limitation of software provenance. npm’s provenance system is designed to provide verifiable information about where and how a package was built, including its source repository, source commit and build workflow.
In this case, those details were legitimate. The package really was built from the Tensorlake repository and published through the project’s authorized workflow. The problem was that attackers had already inserted malicious code into that legitimate source.
In other words, provenance could establish that 0.5.144 came from the claimed Tensorlake build process, but it could not establish that the repository contents at the time of the build were uncompromised.
The distinction is reflected in the npm documentation on trusted publishing and provenance, which describes provenance as evidence about the package’s build origin and process rather than a security certification of the source code.
Tensorlake began rebuilding its release controls
Tensorlake’s post-incident changes included reverting the malicious commits and modifying its CI process to install dependencies with npm ci --ignore-scripts. The project also added checks intended to detect unexpected lifecycle hooks and suspicious files in typescript/lib.
The maintainers further tightened branch protections, added required signatures and changed npm publishing controls so that another member of the operations team must review releases. The project was also bumped to version 0.5.145 in the incident-response work.
The response documentation identified additional remediation work around the compromised GitHub account, revocation of sessions and credentials, removal of administrative privileges and rotation of release-related secrets. The six tensorlake-native-* packages published at 0.5.144 were also identified for removal as part of the response.
Researchers found no evidence at the time of their analyses that Tensorlake’s PyPI or Cargo distributions had been successfully compromised.
The affected npm version remains tensorlake@0.5.144, with 0.5.143 identified by researchers as the last clean release before the malicious changes. Public analyses have not established how many real-world systems installed and executed the malicious version, so the package’s normal download volume should not be treated as a confirmed infection count.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
