A compromised release of the tensorlake npm package has been reported in connection with the ChainDrop / Shai-Hulud supply-chain campaign. The affected package is a TypeScript SDK used for Tensorlake applications, sandboxes, and cloud services, which makes the incident especially relevant for development teams, CI/CD maintainers, and organizations experimenting with AI agent infrastructure.
The reported malicious version is 0.5.144. According to the public reporting, that release included obfuscated malware designed to steal credentials, exfiltrate secrets, establish persistence, and run attacker-supplied code. The immediate takeaway is simple: if your organization installed or built with [email protected], treat the incident as a credential exposure event, not only as a bad dependency update.
What happened
The compromised package reportedly used a preinstall hook to launch JavaScript from inside the package. Preinstall hooks are risky because they can execute automatically during dependency installation, including in developer workstations, build runners, containers, and CI environments. In this case, the loader reportedly invoked additional malware through the Bun runtime and moved into credential theft and self-propagation behavior.
The public analysis describes the malware as part of the Shai-Hulud family: a credential-stealing worm that can search accessible environments for secrets and then attempt to spread through package publishing identities. That combination is dangerous because it can turn one compromised install into a broader software supply-chain incident.
Why this matters beyond one package
Many dependency compromises are handled as version-pinning problems: remove the bad version, update the lockfile, rebuild, and move on. That is not enough here.
The reported behavior includes harvesting credentials from local files, CI environments, Kubernetes, Vault sources, SSH material, npm tokens, GitHub tokens, cloud credentials, .env files, cryptocurrency wallets, messaging app data, and configuration files associated with AI coding tools and editors. If a build runner, developer laptop, or automation account had access to those secrets when the malicious package ran, those secrets should be considered exposed.
The worm behavior also raises the risk of secondary publication. Reporting says the malware can enumerate packages tied to a victim publishing identity and republish compromised versions, using mechanisms such as Sigstore provenance to make the activity look more legitimate. That means maintainers should not only inspect the affected application, but also check whether their own npm packages, GitHub workflows, and release pipelines were altered.
Immediate checks for engineering teams
Start by searching dependency manifests and lockfiles for tensorlake and specifically version 0.5.144. Check package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container build logs, and CI job history. If your organization mirrors npm packages internally, check whether the malicious version was cached.
Next, identify where the package may have been installed. Focus on developer machines, CI runners, ephemeral build containers, package publishing jobs, and any automation environment with broad secrets access. A package install in a privileged CI job is often more serious than an install on a low-privilege test machine because CI usually has deployment keys, registry tokens, cloud credentials, and GitHub permissions.
Then review repositories for unexpected file changes. Public reporting specifically mentions persistence-related writes involving Claude Code and VS Code configuration paths such as .claude/settings.json and .vscode/tasks.json. Treat unexpected workflow, task, editor, or automation configuration changes as suspicious, especially if they appeared after the dependency was installed.
Credential rotation should be broad
If exposure is plausible, rotate credentials rather than trying to prove exactly which secret was read. Prioritize npm tokens, GitHub personal access tokens, GitHub App credentials, CI/CD secrets, cloud provider keys, Kubernetes credentials, Vault tokens, SSH deploy keys, and any signing or publishing credentials available to the affected environment.
For GitHub, review recent commits, workflow changes, new or modified Actions, newly created repositories, suspicious public repositories, new deploy keys, changed branch protection rules, and package publication events. For npm, check package access, recently published versions, newly added maintainers, automation tokens, and provenance records.
Where possible, replace long-lived credentials with short-lived workload identity, OIDC-based CI authentication, scoped tokens, and environment-specific secrets. A worm that searches broadly for credentials is much less effective when each token has narrow permissions and short validity.
Containment and recovery
Remove the malicious package version from affected environments and rebuild from known-good sources. Do not assume that deleting node_modules is sufficient if the malware established persistence or modified repository files. Recreate CI runners if they are not ephemeral, invalidate caches that may contain the compromised package, and rebuild containers from clean base images.
Review outbound network logs for unusual connections around the time of installation. Public reporting mentions command-and-control resolution through an Ethereum contract and a fallback mechanism involving GitHub-hosted staging. Even if those exact indicators are blocked or changed, unusual outbound traffic from build systems should be investigated.
If your organization publishes packages, temporarily pause automated releases until tokens are rotated and repository integrity is confirmed. For critical packages, consider notifying downstream users if there is evidence that compromised credentials may have been used to publish new versions.
Longer-term lessons
This incident reinforces a recurring supply-chain lesson: dependency install scripts are executable code. Teams should consider disabling lifecycle scripts in high-risk workflows where practical, separating dependency resolution from privileged build stages, and running package installs in isolated environments without production secrets.
AI development tooling deserves special attention. The reported targeting of configuration files associated with AI coding tools and editors shows that attackers understand where modern engineering workflows are moving. Agent tools, editor tasks, MCP configurations, and local automation can all become persistence points if they run commands automatically or inherit sensitive context.
For security teams, the right response is not panic, but disciplined scoping: find installs, identify exposed environments, rotate secrets, inspect repositories, and harden CI. The most important mistake to avoid is treating the incident as a single vulnerable package instead of a potential credential and publishing-chain compromise.
Source: The Hacker News