Tensorlake npm Compromise: Exposure and Safe Recovery

What happened

On October 8, 2026, Socket reported malicious code in tensorlake@0.5.144, the npm SDK used to interact with Tensorlake's applications and AI sandbox infrastructure. The release contains an installation hook that starts an obfuscated loader and a credential-stealing payload associated by researchers with the ChainDrop / Shai-Hulud family.

The security boundary matters: the reported code executes on the machine installing the SDK, before an application needs to import it or send generated code to a sandbox. This is not evidence of an escape from Tensorlake's sandbox isolation.

Independent analyses from StepSecurity and SafeDep corroborate the malicious release and add details about repository compromise, conditional execution, persistence, and recovery. Tensorlake's merged remediation pull request confirms that malicious commits reached the main branch under a repository-administrator account and were released through the project's own workflow. This does not establish how that account was initially compromised or imply deliberate misconduct by the maintainer whose identity was used.

Timeline and current status

• October 7: StepSecurity traces the first malicious source commit to approximately 01:20 UTC, followed by additional changes to the loader and package manifest.
• October 8, 01:12:07 UTC: Socket and SafeDep identify the publication of tensorlake@0.5.144.
• Shortly afterward: SafeDep reports an automated alert at 01:20 UTC; Socket reports flagging the package at 01:23:10 UTC. These are separate detection timestamps, not a verified containment window.
• During October 8: later reporting and the maintainer's remediation pull request confirm removal of the main npm release. Pull request #1016 was merged to revert the malicious changes, harden publication, and bump the project to 0.5.145. SafeDep reports that 0.5.145 was released.

Registry removal does not remove cached packages, existing installations, or persistence. Download counts for the overall package are not counts of affected installations or confirmed victims.

Who is affected

Prioritize developer workstations and other environments that installed tensorlake@0.5.144 with lifecycle scripts enabled. Include direct and transitive dependency resolution, historical lockfiles, shared caches, container build stages, and source checkouts of the affected repository during the compromise window.

StepSecurity and SafeDep report that the analyzed loader skips execution when it recognizes certain CI environments. This qualifies the broader observation that the payload contains functionality for harvesting CI and cloud secrets: a capability in the payload is not proof that it ran in every pipeline.

Do not declare all CI installations safe on that basis. Package-manager settings, environment detection, alternate execution paths, source builds, and later changes affect the outcome. Establish whether the loader and payload executed from logs and endpoint evidence. An artifact containing the package and a host executing its malware are different findings, and both require tracking.

The confirmed malicious npm version is 0.5.144. The maintainer's response also identifies six tensorlake-native-* packages from the same release for withdrawal. That shared release provenance warrants inventory and quarantine review, but does not independently prove that every native package contains the same JavaScript payload. A cross-language version bump is likewise not evidence that the Python distribution was infected.

No campaign-specific CVE or CVSS score is established in the sources reviewed. This is a malicious software-release incident, not a conventional vulnerability requiring an exploit against a particular runtime version.

Why it matters

Installing a dependency can grant its scripts access to the installer's files, environment, network, and available credentials. A development workstation can therefore become an entry point into cloud services, repositories, package registries, and deployment systems without the application ever starting.

The reported malware combines collection, remote execution, propagation, and persistence. Updating the dependency alone cannot establish that the device or its accounts are clean. A compromised publishing identity can also expose downstream users through new releases of otherwise legitimate packages.

The incident demonstrates a limit of provenance rather than a reason to abandon it. An attestation can correctly identify the workflow and source used for a build while those inputs are malicious. GitHub's verified commit status and npm provenance should inform origin verification, not replace source review, account security, or release approval.

Technical details

Installation-time execution

The malicious manifest invokes lib/setup.mjs during the preinstall lifecycle. Researchers describe this as an obfuscated loader that uses Bun to execute lib/Math_Symbol.js. No application-level import is necessary when that hook is permitted to run.

npm's official documentation confirms that installation operations, including npm ci, can invoke lifecycle scripts. Reproducible installation does not make a maliciously pinned version safe. Conversely, disabling lifecycle scripts blocks this reported installation route, but does not disinfect an existing host or prevent explicitly running untrusted code later.

Credential access and propagation

The analyses describe collection of npm and GitHub tokens, cloud credentials, Kubernetes and Vault material, SSH keys, environment files, and AI-development-tool configuration. SafeDep also describes a browser-password collection component, while qualifying its identification of the external binary because that binary was not recovered.

Collection depends on what the executing identity can actually access. The presence of an AWS, Kubernetes, or Vault collection routine does not imply that those services were universally breached. Investigate the permissions, sessions, and resources exposed on each affected machine.

StepSecurity reports modifications to reachable repositories, including Claude Code settings and VS Code task configuration, intended to reintroduce execution through developer workflows. Researchers also describe unauthorized package publication and GitHub workflow manipulation. Review these changes as potentially executable configuration, not merely cosmetic project metadata. Actual execution still depends on the relevant tool's settings and trust decisions.

Updated command-and-control findings

Socket's initial account describes endpoint discovery through an Ethereum contract and a GitHub fallback, without a hardcoded domain. SafeDep's more detailed analysis of the published sample identifies iseekaigogo[.]com as a configured endpoint, with blockchain and GitHub fallback mechanisms; StepSecurity also identifies that domain.

For defensive purposes, treat the domain as one reported indicator, not a complete network containment strategy. Infrastructure can change, and fallback mechanisms reduce the value of relying on a single destination block. The domain is defanged here for historical correlation only; do not browse it or contact the malware's infrastructure.

The token-revocation trap

Socket, StepSecurity, and SafeDep describe a background token monitor that checks whether a stolen GitHub token remains valid and can trigger destructive deletion of the user's home directory when it is rejected. Persistence is reported through a Linux user service, a macOS LaunchAgent, or a Windows scheduled task.

SafeDep identifies additional conditions in the analyzed build, including an organization-membership check before arming the watcher, and reports checks roughly every minute for up to 24 hours. These findings should not be treated as a reliable safety exemption for a particular user or as a reason to wait for an assumed timer to expire. Variants, incomplete telemetry, and other persistence can change the risk.

This incident requires a coordinated recovery sequence: contain execution, neutralize the monitor and its restart mechanisms on affected machines, then promptly revoke and replace exposed credentials from a trusted environment. Revocation performed on another device can still be observed by malware running on the original host. Network isolation alone is not proof that the monitor has been disabled.

Detection and investigation

Start with historical package resolution, installation logs, and endpoint timelines. Record which version was present, whether install scripts were permitted, whether the loader exited early, and what follow-on processes or network connections appeared. Do not reinstall the malicious release to test exposure.

Correlate these reported artifacts rather than relying on filenames alone:

• lib/setup.mjs and lib/Math_Symbol.js within the affected package, especially an unexpected new install hook.
• Unexpected Bun execution associated with a dependency installation. Bun itself is legitimate; parentage and payload provenance matter.
• gh-token-monitor services, launch entries, scheduled tasks, or related files, including ~/.config/gh-token-monitor/ and the Windows local-application-data monitor directory.
• Unapproved changes to .claude/settings.json, .vscode/tasks.json, or GitHub Actions workflows in repositories accessible to the affected identity. Avoid opening suspect projects with automatic tasks or hooks enabled during review.
• Newly created public repositories, unexpected releases, changed publishing permissions, and unexplained repository or workflow activity. Researchers identify the repository description "Shai-Hulud: Here We Go Again" as one investigation lead.

The published SHA-256 indicators agree across Socket, StepSecurity, and SafeDep:

• lib/setup.mjs: 25a0735d0db7dc40e5d45ce42d9c106067e6a66e184d967cfecfab17c3bcb5ef
• lib/Math_Symbol.js: b50a00900399ba99fb6ce1fc151519cb99d44320ef2a631f2237e1aea0ad6fec

A hash match identifies the known sample; absence of a match does not rule out earlier builds or modified persistence. Preserve evidence before purging caches or deleting files, and keep captured secrets out of shared tickets and routine logs.

Recommended actions

Contain and recover in the right order

1. Block tensorlake@0.5.144 in dependency controls and suspend affected installations and releases. Inventory associated native packages and retained artifacts without assuming the public registry's state reflects internal mirrors.
2. Contain suspected execution environments using approved incident-response procedures. Preserve relevant evidence and protect important data through trusted backup mechanisms. Do not use the affected machine to administer recovery credentials.
3. Have responders stop and disable the token monitor and all identified restart mechanisms on every affected host that may hold the same token. Investigate repository hooks and other persistence as well. Do not trigger token invalidation as a diagnostic test. If safe neutralization cannot be established promptly, escalate containment and credential decisions to the incident lead rather than leaving exposed access active indefinitely.
4. Once the revocation trap is neutralized, promptly revoke and replace exposed GitHub tokens and other accessible credentials. Scope cloud, npm, SSH, Kubernetes, Vault, browser, and AI-service access according to evidence and permissions. Invalidate relevant sessions where supported and audit for use before revocation.
5. Investigate downstream propagation. Review package publications, source changes, workflow permissions, release artifacts, and connected identities. A dependency update does not undo changes already pushed into other repositories.
6. Rebuild compromised environments from trusted sources when integrity cannot be established. Restore reviewed configuration only, regenerate affected artifacts, and remove quarantined caches after evidence preservation. Verify that persistence and unauthorized activity do not recur before restoring secret access.

Choose a verified replacement

StepSecurity's initial advisory recommended 0.5.143 as a temporary rollback. The merged maintainer remediation prepares 0.5.145, and SafeDep subsequently reports its release. Prefer the maintainer-confirmed recovery release or a later explicitly reviewed release after verifying the actual registry artifact, dependency tree, and advisory status. This article does not independently certify the contents of every replacement artifact.

Do not interpret a larger version number, an updated latest tag, or successful installation as proof of recovery. Keep the affected version explicitly blocked even after replacing it.

Harden the development and release workflow

Disable unnecessary installation scripts and review exceptions. npm documents ignore-scripts as suppressing package scripts while still allowing explicitly requested commands such as npm run to execute their intended script. Validate policy against the package-manager version actually deployed; test builds for dependencies that genuinely require installation steps.

Separate dependency installation from publishing and deployment privileges. Use ephemeral build environments, read-only dependency credentials where possible, constrained egress, and narrowly scoped access to secrets. An agent sandbox does not protect a separate, credential-rich SDK installation environment.

Use trusted publishing to reduce reliance on long-lived npm write tokens, while protecting the authorized workflow itself. npm recommends restricting traditional token-based publication after migration. Apply branch protection without broad administrator bypasses, independent release approval, and review of workflow or executable-configuration changes. Tensorlake's remediation documents similar changes to its branch and publishing controls.

Retain provenance checks, but combine them with artifact inspection, lifecycle-script policy, and release review. The decisive question is not only where a package was built, but whether trusted identities and workflows were authorized to publish that exact content.

Sources

• Socket: TensorLake npm SDK compromise, October 8, 2026
• StepSecurity: Tensorlake npm compromise and token-monitor response guidance
• SafeDep: tensorlake 0.5.144 analysis and updated findings
• Tensorlake: merged remediation and release-hardening pull request #1016
• npm documentation: lifecycle scripts
• npm documentation: ignore-scripts configuration
• npm documentation: trusted publishing

Source review date: October 8, 2026. Findings and recovery guidance may evolve as the investigation continues.