TL;DR
-
A malicious release of TensorLake's TypeScript SDK, tensorlake@0.5.144, used an install hook to search for developer credentials and accept remote commands.
-
Sonatype's code review found that its GitHub fallback could create a public repository and commit collected data, including a stolen GitHub token in one path, and that the malware could modify accessible repositories by committing .claude and .vscode files.
-
The loader exits under several common CI environment markers, so the payload's separate GitHub Actions logic does not establish broad CI infection.
-
We have not confirmed that stolen data was published, repositories were modified, or downstream systems were affected. Anyone who installed the release should determine whether the hook ran, investigate the host and accessible GitHub repositories, and review credentials available to the process.
A Malicious Install Hook Launches the Payload
The affected npm release included a preinstall hook that starts an obfuscated JavaScript payload through Bun. The package can download Bun 1.3.13 if it is not already available.
The TensorLake TypeScript SDK's documented purpose is to work with sandboxes, repositories, and cloud services. Credential collection and remote command execution are unrelated to those functions.
The payload searches local sources for secrets, including GitHub tokens and HashiCorp Vault credentials, and sends collected data to remote infrastructure. Its collection lists also target files associated with AI development tools, including Claude, Cursor and Kiro MCP configuration, Codex authentication, Gemini OAuth credentials, and Windsurf authentication and configuration.
It also polls a command channel and evaluates JavaScript supplied by the operator. Sonatype Research Labs identified a GitHub-based fallback in the code that can also publish collected data.
The GitHub Fallback Can Expose Collected Data
Initial analysis from Socket describes GitHub as an alternate command-and-control route.
Sonatype Research Labs also identified this behavior in the code, and found that the fallback has another function: when it activates, the code can create a public GitHub repository by setting private: false and commit collected data beneath results/.
Within the GitHub fallback path, when a collected GitHub token has repository scope and a Gists API request returns an empty list, the code includes the token in the uploaded data and commit message. If repository creation and the commits succeed, that token could become publicly accessible.
Token Access Allows Repository Modification
Worm-like malware can turn one compromised developer environment into a path toward others. When self-replicating malicious code reaches a developer's credentials, the attack surface massively expands as it reaches additional teams through common platforms or tools.
In this incident, the code's repository-modification logic makes that possibility important to investigate, although we have not confirmed downstream spread.
The code also contains explicit logic to modify the repository associated with the execution context, enabling it to commit .claude and .vscode setup and configuration files across eligible branches. This could lead to exposing other developers to the payload when they use the affected repository, depending on how those files are loaded and executed by their tools.
The code below contains the configuration of the GitHub repository, including the settings that make it publicly accessible.
The Install Hook Checks for CI Before Launching the Payload
The package's setup.mjs checks several environment variables before it launches the payload. It exits when CI is exactly true or 1, when GITHUB_ACTIONS or GITLAB_CI is true, or when RUNNER_ENVIRONMENT is github-hosted. This confirms that the install hook skips those specific environments when those markers are present. It does not establish why the code checks them or whether CI systems were outside the campaign's intended scope.
One possibility is that the hook focused on developer workstations, where it could find credentials, AI-tool configuration, and opportunities for persistence. That explanation is plausible, but remains an inference. The code's behavior alone does not establish the attacker's intent.
The payload also contains GitHub Actions and repository-modification logic. One hypothesis is that this logic could provide another execution route, such as direct execution from a planted workflow that bypasses setup.mjs. We have not established that connection. The code could also contain inherited or inconsistent logic from another variant.
The confirmed finding is limited to the loader's checks for those specific CI markers. We have not confirmed broad CI infection, but the skip behavior alone does not show that CI systems were outside the campaign's intended targets.
A Package-Specific Correlation Clue
The payload sets globalThis.WORMTAG to "tensrlake". Researchers can use this exact string to search for related samples and activity.
This can help with correlation, but cannot alone confirm that another incident is related.
What Affected Teams Should Do First
Anyone who installed `tensorlake@0.5.144` should treat credentials available to that environment as potentially exposed until reviewed. Check manifests, lockfiles, package caches, and build records for the affected version, then determine whether the preinstall hook executed. Investigate the host and any development or build environments where it ran.
Before rotating credentials, check for the reported token-monitor component. Public analysis warns that revoking a stolen GitHub token while this monitor is active may trigger destructive behavior. If present, remove or disable the persistence mechanism before revoking that token, then rotate credentials that were accessible to the process.
Review GitHub audit activity for unexpected access, repository creation, and commits across branches. Inspect .claude, .vscode, and results/ paths, and check for public repositories created during the relevant period. Review HashiCorp Vault audit logs for unexpected credential access. Rebuild from a clean environment after investigation.
Removing the package does not revoke credentials it may have read. Likewise, npm removing a release does not remove copies already installed or determine whether the payload executed.
Investigate the Behavior; Confirm the Impact
The TensorLake release shows why install-time behavior deserves the same scrutiny as the package's advertised features. Its code could collect credentials, accept remote commands, publish collected data through a public GitHub repository, and modify repositories the stolen token could access.
Those capabilities make the release serious, but they do not establish that data was published or downstream repositories were compromised.
Teams that installed tensorlake@0.5.144 should verify whether the hook ran, inspect relevant hosts and GitHub activity, and respond to any exposed credentials based on what their investigation finds.
Sonatype Research Labs is continuing to investigate the Tensorlake compromise and will update sonatype-2026-009038 as additional components, indicators, and impact are confirmed.
