Tensorlake npm Package 0.5.144 Compromised: How to Check Exposure and Respond

Direct answer

If tensorlake@0.5.144 was installed, identify every developer workstation, build runner, container image, and deployment host where its install script could have run. Contain those systems, preserve evidence, and treat reachable secrets as potentially exposed. Rotate credentials from a clean system, check repositories and cloud accounts for unauthorized changes, remove persistence, and rebuild uncertain hosts. Do not equate package downloads with confirmed infections.

What happened on October 8, and what is confirmed?

The affected npm release is tensorlake@0.5.144. Socket recorded the original package publication at October 8, 2026, 01:12:07 UTC. Tensorlake’s GitHub issue #1014 was opened at 01:22:02 UTC, providing a near-real-time first-party record that the package was being investigated. Aikido and Socket independently described the same version and the same install-time file sequence; StepSecurity separately reported its own analysis and notified the maintainers through that issue.

The confirmed security problem is a malicious npm package release, not a newly assigned vulnerability in the Tensorlake service. There is no CVE established for this incident in the reviewed evidence. The reports describe malware capable of collecting credentials, communicating outward, and attempting propagation. That is different from proving that a particular reader’s secrets were stolen, that every installation was successful, or that a particular organization was compromised.

The incident has been associated by researchers with the Shai-Hulud or ChainDrop family and pattern. That is a family or behavioral assessment, not identification of the operator. No reviewed source establishes an operator identity or a confirmed victim total.

Which npm release and install-time files are affected?

The reported affected version is specifically 0.5.144. In the published package manifest, Socket identified a preinstall entry that invokes node lib/setup.mjs. Aikido and Socket both identified lib/setup.mjs as an obfuscated loader and lib/Math_Symbol.js as the obfuscated payload. StepSecurity also described the loader as retrieving or using the Bun runtime before running the larger payload.

That detail matters because npm lifecycle scripts can run during installation when an organization’s package-manager policy permits them. A user does not necessarily need to import Tensorlake, call an SDK method, or execute an AI-agent task for the install-time path to become relevant. Conversely, a lockfile entry alone does not prove that the package was installed or that the script ran. The investigation must connect the version to an actual install event and an actual host.

The reports do not support treating every Tensorlake artifact as malicious. They identify 0.5.144 as the version under investigation. Do not declare another version safe solely because its number is different; verify current maintainer and registry guidance before adopting it. A valid provenance attestation, where present, also does not certify that the source code was benign. StepSecurity specifically used this incident to illustrate that provenance can describe a build origin without guaranteeing the integrity of the code that was built.

Why an AI sandbox does not protect the installing host

Tensorlake is designed to provide isolated environments for agent workloads. That isolation can be valuable at runtime, but it does not automatically sandbox the package manager that installs the SDK. A lifecycle hook executes with the permissions and network access available to the installing process.

On a developer laptop, that may include source repositories, SSH material, cloud configuration, browser stores, local package credentials, and AI-development-tool configuration. On a build runner, it may include short-lived cloud credentials, repository tokens, artifact-registry credentials, signing material, or environment variables injected for a pipeline. In a container build, the risk depends on whether installation happened during image construction, what files and secrets were present, and whether the resulting layers or caches were retained.

A payload’s ability to read a credential is not proof that it successfully exfiltrated that credential. It is, however, enough to make exposure triage urgent when the host had access to sensitive material. The safest decision boundary is the point at which the script could have run, not the point at which the application later used the SDK.

What may the payload have targeted?

Across the reviewed investigations, reported target categories include npm and GitHub credentials, cloud credentials, Kubernetes and Vault material, SSH keys, environment files, local configuration, browser data, cryptocurrency wallets, and configuration associated with AI coding tools. Aikido listed numerous CI-related environment variables and credential locations; Socket highlighted CI, Kubernetes, Vault, cloud, local files, and AI-development configuration; StepSecurity described saved browser logins and editor or agent files.

Use those categories to build an inventory, not to assume every item was present or taken. Ask which identity the installer used, which directories were readable, which environment variables were injected, whether outbound network access was available, and whether the host had write access to repositories or package registries. The answer will differ sharply between a restricted workstation, a privileged release runner, and a developer machine used for cloud administration.

How to check lockfiles, installs, and build records

Start with an organization-wide search for the exact name and version, including transitive dependencies:

Do not use the package’s overall popularity as a proxy for the incident’s scope. Aikido reported a package-wide lifetime install figure above 100,000, while Socket reported approximately 12,000 weekly downloads for the package. Those measurements cover the package in general, not confirmed downloads of 0.5.144, malicious-version installs, unique hosts, or victims.

• Search package.json, npm lockfiles, shrinkwrap files, monorepo manifests, dependency caches, and artifact inventories for tensorlake@0.5.144.
• Review npm, package-manager, CI, and build logs for installs between the release time and the point at which the version was blocked or removed.
• Check developer workstations, ephemeral runners, container-build hosts, shared build images, and deployment systems separately. A package can be present in a lockfile without having run, while a cache or image layer can preserve evidence after the working directory is deleted.
• Record the host, account, job, timestamp, package-manager settings, and whether lifecycle scripts were enabled. Preserve relevant logs and a copy of suspicious files for the incident team before cleanup.
• Look for unexpected package publications, repository commits, workflow changes, new repositories, unfamiliar deploy keys, cloud access, or registry activity associated with identities that were available to the installing host.

How to contain an affected workstation or runner

If the script ran, or if the evidence is inconclusive on a host with valuable access, isolate the host from normal network activity while preserving the information needed for investigation. Stop using it for development, releases, and administrative access. Suspend automated jobs that could republish packages or modify repositories. Block the affected version in dependency policy and prevent it from entering new builds.

Coordinate prompt host containment and credential revocation with the response team. Some investigations describe persistence and token-monitor behavior, although their detailed narratives differ. Where possible, isolate affected hosts first and handle suspected destructive persistence alongside revocation; this is not a reason to leave exposed credentials active indefinitely. Examine unexpected user services, logon tasks, scripts, editor or agent configuration and other persistence. If the organization cannot establish that the host is clean, rebuild it from a trusted image rather than trying to disinfect it in place.

For CI, preserve the runner’s logs and workspace evidence, then retire or recreate the runner according to the platform’s incident process. A job that did not retain a long-lived filesystem can still have exposed the secrets and permissions available during its run. Rotate those credentials based on access, even if no suspicious outbound event is found.

How to rotate credentials and check persistence safely

Perform rotation from a known-clean device or freshly built administrative environment. Prioritize identities with administrator or publication privileges and suspected active abuse; then work through the host’s actual access inventory. That can include package and source-control tokens, cloud keys and role sessions, registry and signing material, deployment credentials, Kubernetes and Vault access, SSH keys, AI-service keys, and passwords or sessions stored on the affected host. The correct order depends on the environment, not a universal list.

Use the provider’s normal revocation and replacement controls, and record the time each credential was invalidated. Review audit logs for use before and after the suspected install. Search for new package versions, altered release workflows, unfamiliar repository changes, unexpected cloud resources, new access keys, and changes to CI secrets. If browser or wallet data was accessible, use the relevant provider’s account-recovery and transaction-monitoring process rather than relying on a local scan.

Persistence checks should be broad but non-destructive: inspect user-level services, scheduled or logon tasks, startup entries, shell or profile changes, repository automation files, editor configuration, and unfamiliar binaries or scripts created around the installation window. Preserve suspicious artifacts before removal. Removing a package directory does not necessarily remove a second-stage file or a persistence mechanism.

What the differing C2 reports mean

Aikido reported a hardcoded endpoint and a blockchain-based mechanism for resolving an alternate endpoint. Socket’s analysis said its observed payload did not have a hardcoded command-and-control domain and instead described an Ethereum-contract resolver with a GitHub fallback. StepSecurity reported communication to an endpoint and data being placed in a repository created in a victim account.

Those accounts may reflect different samples, analysis stages, or interpretations of overlapping code, but the reviewed sources do not justify collapsing them into one settled narrative. The defensible conclusion is narrower: the payload was reported to have outbound communication and exfiltration or propagation mechanisms, and responders should use current indicators from their incident-intelligence provider while examining network and account logs. This article intentionally does not present a single endpoint, blockchain detail, or propagation path as the complete story.

FAQs

Question: Was tensorlake@0.5.144 malicious, and is another version automatically safe?

The reviewed investigations identify 0.5.144 as the compromised release and describe its preinstall loader and payload. That does not make every other release malicious, but it also does not prove another version is safe. Confirm the current package status, maintainer response, and registry metadata before updating or pinning a replacement. Keep lifecycle scripts restricted where practical, and test dependency changes in a controlled environment.

Question: What if 0.5.144 was installed but the application never imported it?

Importing the SDK is not the only relevant event. If npm lifecycle scripts were enabled, the preinstall hook could have run before application code used the package. Investigate the installing workstation, runner, image-builder, or server, along with the credentials and network permissions available at that time. A lockfile-only reference, by contrast, is an indicator to investigate rather than proof that the hook executed.

Limitations and what this article does not establish

This article reflects the reviewed technical reports and repository issue available on October 8, 2026. Package status, indicators, maintainer guidance, and additional affected versions can change. The sources do not establish a confirmed victim count, a confirmed successful theft from a specific organization, or an operator identity. They also differ on parts of the command-and-control description and on some repository-commit details; those differences are attributed rather than resolved by assumption.

The guidance is incident-response information, not a substitute for the organization’s forensic, legal, cloud-provider, or identity-provider procedures. Do not publish indicators or take destructive remediation steps without validating them against current evidence and preserving what investigators need.

Decision checklist

• Identify: Find tensorlake@0.5.144 in manifests, lockfiles, caches, images, logs, and endpoint inventories.
• Scope execution: Determine where installation occurred, whether lifecycle scripts were enabled, and which identity and secrets were available.
• Contain: Isolate uncertain hosts, pause release and publication workflows, and block the affected version.
• Preserve: Save logs and suspicious artifacts before deleting or rebuilding anything.
• Inspect persistence: Review user services, scheduled tasks, startup changes, repository automation, editor or agent configuration, and unexpected files.
• Rotate cleanly: Replace reachable package, source-control, cloud, registry, cluster, vault, SSH, AI-service, and browser credentials from a clean environment.
• Hunt for spread: Audit repositories, package publications, workflow changes, cloud activity, and new access paths.
• Rebuild: Recreate affected hosts and runners from trusted sources; verify the replacement dependency independently.
• Document: Preserve the timeline, affected identities, evidence, actions, and remaining uncertainty for legal, compliance, and follow-up decisions.

Limitations

• Evidence was reviewed on 8 October 2026; advisories, telemetry and package status can change.
• General defensive guidance is not a diagnosis of a particular system or a guarantee of complete cleanup.
• Capabilities, exposure and sensor attempts do not alone establish confirmed data theft or a customer breach.
• Source guidance and indicators must be rechecked before making operational decisions.

Evidence sources

1. Aikido — Aikido technical analysis
2. First-party researcher/project repository — Tensorlake repository issue #1014
3. Socket — Socket independent package analysis
4. StepSecurity — StepSecurity threat research