A malicious version of the Tensorlake npm SDK has been compromised in a software supply chain attack that delivers an obfuscated credential-stealing worm. The affected release, version 0.5.144, is part of a package used to provide TypeScript infrastructure for AI agent sandboxes and normally sees around 12,000 weekly downloads. The project also has more than 1,000 stars on GitHub, giving the attack the potential to affect a meaningful number of developers and development environments.
The compromised package was identified shortly after publication on 8 October 2026. What makes the incident particularly dangerous is that developers do not need to actively use the library after installation for the malicious code to run. The infection begins automatically through an npm lifecycle script when package managers allow those installation hooks to execute.
Malicious Code Runs During Package Installation
The attack starts through a preinstall lifecycle script inside the package manifest. During installation, the script launches node lib/setup.mjs, allowing the malicious loader to execute before a developer has even imported the package into an application.
This makes the compromise especially effective because simply adding or updating the dependency can be enough to trigger the infection. There is no requirement for the developer to start an AI agent, call one of the package's functions or manually execute the malicious component. Once npm allows the lifecycle hook, the attack begins automatically.
The compromised loader is heavily obfuscated, making casual inspection more difficult. It subsequently launches another payload named Math_Symbol.js using Bun, after which the malware begins examining the local development environment for credentials and authentication material.
The Worm Targets NPM And Developer Credentials
One of the first areas targeted is npm authentication. The malware reads local .npmrc files and attempts to obtain credentials through npm token APIs and OpenID Connect exchange endpoints. These credentials can be particularly valuable because they may allow attackers to publish new versions of packages owned by the compromised developer.
That publishing access is what enables the malware to behave as a worm rather than simply a conventional information stealer. Once credentials are obtained, the attack can move from one compromised developer account to additional packages controlled by that person or organisation.
For maintainers with access to multiple npm projects, a single infected workstation could therefore become the starting point for a much wider supply chain compromise.
Cloud Infrastructure Credentials Are Also Targeted
The malware also looks beyond npm credentials and attempts to collect secrets associated with cloud environments. It queries several AWS-related services and metadata sources, including instance metadata services, ECS environments, Systems Manager Parameter Store and AWS Secrets Manager.
These sources can contain highly sensitive credentials used by applications and infrastructure. If successfully extracted, they could give attackers access to cloud resources well beyond the developer machine where the infection began.
This significantly increases the potential impact of the compromise. What initially appears to be a malicious JavaScript package could ultimately expose production infrastructure, deployment environments and internal cloud services.
HashiCorp Vault Is Another Target
The payload also probes local HashiCorp Vault deployments using the common address 127.0.0.1:8200. It reportedly checks both Kubernetes and AWS authentication paths when interacting with Vault.
Vault is commonly used to centralise and protect sensitive secrets such as API keys, service credentials and certificates. An attacker who can access a developer's local Vault configuration or authenticated session could potentially obtain credentials intended for much more sensitive environments.
The malware's interest in these systems suggests that the campaign is designed specifically around developer and DevOps environments rather than general consumer devices.
AI Development Tools Are Being Searched Too
The ChainDrop payload also searches for configuration files associated with several popular AI-assisted development tools. Targeted directories include .claude, .cursor, .kiro, Windsurf and Zed.
These configurations may contain authentication information, project details or credentials associated with development platforms and AI services. As AI-assisted coding tools become increasingly common, their local configuration directories are becoming more attractive targets for credential-stealing malware.
The attack therefore reflects a broader shift in supply chain threats. Modern developer workstations often hold access to source repositories, cloud platforms, package registries and AI development services all at once, making them extremely valuable targets.
The Worm Can Infect Other NPM Packages
The attack does not stop after stealing credentials. The malware catalogs npm packages associated with the compromised account and attempts to use those publishing privileges to propagate itself.
It can manufacture Sigstore provenance records before publishing infected package versions directly to the npm registry. Provenance systems are normally intended to improve trust by helping users verify where software came from, so the ability to create apparently legitimate provenance data makes the compromise more deceptive.
By infecting packages already associated with a trusted maintainer, the worm can potentially spread without needing to convince users to install a completely unknown dependency.
GitHub Actions Are Used For Additional Persistence
The malware also plants malicious GitHub Actions workflows into repositories. These workflows are disguised as legitimate maintenance automation and may appear to be associated with tools such as Dependabot or GitHub Copilot.
This camouflage makes the malicious workflows easier to overlook during casual repository inspection. Developers are accustomed to automated dependency updates and maintenance jobs, so a workflow that appears to belong to a familiar platform may not immediately raise suspicion.
Once added, these workflows can provide another mechanism for the attackers to maintain access or continue propagating malicious changes.
Command And Control Uses Ethereum Rather Than A Fixed Server
Another unusual feature is the way the worm discovers its command-and-control infrastructure. Instead of embedding a conventional domain name or IP address, it queries an Ethereum smart contract to determine where it should communicate.
The malware checks roughly 30 public Ethereum RPC endpoints when attempting to retrieve this information. GitHub is also used as a fallback communication mechanism.
Using decentralised infrastructure makes disruption more difficult because defenders cannot simply block or seize one command-and-control server. The attacker can change instructions through the blockchain-based mechanism without republishing the malware itself.
This approach also makes static detection more complicated because the final destination may not appear directly inside the malicious package.
The Attack Resembles Earlier Self-Propagating NPM Campaigns
The ChainDrop compromise shares similarities with techniques previously observed in the Shai-Hulud campaign involving packages such as keyv and cacheable. In both cases, stolen publishing privileges are used to compromise additional packages and extend the attack through the software ecosystem.
This type of self-propagating supply chain attack can be particularly dangerous because trust relationships become the distribution mechanism. Developers may confidently install a package they have used for years, unaware that a legitimate maintainer account has been compromised.
The attack therefore demonstrates why package reputation alone is not sufficient protection. Even well-known projects can become malicious temporarily if an attacker gains control of the publishing process.
Persistence Mechanisms Differ Across Operating Systems
The malware installs monitoring mechanisms designed to maintain persistence and watch the victim's GitHub credentials. The implementation changes depending on the operating system.
On Windows, the malware creates an ONLOGON scheduled task that runs monitor.ps1. Linux systems receive a gh-token-monitor.service, while macOS installations use a launch configuration named com.user.gh-token-monitor.plist.
These components repeatedly query api.github.com/user, allowing the malware to detect whether the compromised GitHub token remains valid. This behaviour introduces one of the most dangerous aspects of the attack: a destructive dead-man switch.
Revoking The GitHub Token Can Trigger Data Destruction
Security teams would normally respond to credential theft by immediately revoking compromised tokens. In this campaign, doing that while the malicious monitor is still active can have destructive consequences.
If the monitor detects that the stolen GitHub token has been revoked, the malware activates a dead-man switch designed to wipe the user's home directory. Importantly, it does not matter where the token revocation occurs. The destructive action is triggered locally when the monitoring component notices that authentication has stopped working.
This creates a difficult incident-response situation because one of the most obvious remediation steps can itself trigger additional damage if performed in the wrong order.
Containment Must Happen Before Credential Rotation
Because of the dead-man switch, remediation needs to be handled carefully. Security teams should first isolate the affected device and disable the persistence and monitoring mechanisms before revoking stolen credentials.
Once the active monitoring components have been removed or neutralised, organisations can begin rotating exposed GitHub, npm, cloud and other authentication credentials. Systems should also be checked for planted GitHub Actions workflows, unauthorised package publications and other persistence mechanisms.
Affected dependencies should then be rolled back to verified clean versions. Development environments may also require a broader review because credentials extracted by the malware could have already provided access to external infrastructure.
Developer Machines Should Be Treated As High-Value Systems
The ChainDrop campaign illustrates how valuable developer workstations have become to attackers. A single machine may contain npm publishing tokens, GitHub credentials, cloud access, Vault sessions and configuration data for multiple AI development platforms.
Compromising one developer can therefore provide access to numerous downstream systems. If that developer also maintains popular open source packages, the attack can potentially spread to thousands of other users through trusted dependency channels.
This is why development endpoints increasingly need security controls comparable to those applied to production infrastructure. Dependency monitoring, credential isolation, endpoint detection and careful management of package lifecycle scripts are becoming essential parts of software supply chain security.
Final Thoughts
The compromise of Tensorlake SDK version 0.5.144 demonstrates how sophisticated modern software supply chain attacks have become. ChainDrop does far more than steal credentials: it targets npm, GitHub, cloud infrastructure, Vault and AI development environments, then uses compromised publishing privileges to spread through additional packages.
The dead-man switch makes the incident particularly dangerous because blindly revoking stolen GitHub tokens can trigger destruction of the user's home directory while the monitoring process remains active. Organisations that installed the compromised release should therefore isolate affected systems, disable persistence mechanisms first, then rotate credentials and restore dependencies from verified clean versions.
For developers, the broader lesson is that installing a dependency is increasingly a security-sensitive action. In an ecosystem where lifecycle scripts can execute automatically and trusted maintainer accounts can be compromised, software supply chain security needs to begin long before an application ever reaches production.
Comments 0