One malicious version can execute during installation

Socket and StepSecurity identified malicious code in tensorlake@0.5.144, published on 8 October. The package manifest adds a preinstall hook, so the loader can run when a developer installs the dependency—even if the application never imports the SDK. The researchers report credential collection, exfiltration and attempts to spread through npm packages and repositories accessible to the victim.

StepSecurity says the affected release was built from malicious files committed to the project's main branch and carried an npm provenance attestation. That attestation establishes a build origin; it is not a safety verdict. Socket's estimate of roughly 12,000 weekly package downloads describes normal package usage, not the number of installs of this malicious release or confirmed victims.

Do not rotate the monitored GitHub token first

Sequence matters

StepSecurity reports a persistent gh-token-monitor that checks a stolen GitHub token and may delete the user's home directory if revocation makes the token invalid. If an installation may have executed, involve incident response, preserve essential data and identify and disable that monitor on the affected host before revoking the token. Follow the researchers' current, platform-specific instructions; do not run generic cleanup commands blindly.

This is a reported capability of the analyzed payload, not evidence that every install created the monitor. Socket and StepSecurity describe different parts of the behavior; the safe assumption for a potentially affected workstation is to check for persistence before a credential-reset campaign.

Scope execution, secrets and secondary changes

  1. 1

    Stop new exposure. Block tensorlake@0.5.144 in package policy and identify its presence in lockfiles, dependency inventories and build records. Verify a clean version with the maintainer and registry before reinstalling.

  2. 2

    Separate download from execution. Determine which developer hosts or runners actually ran lifecycle scripts. Treat a host where the malicious hook executed as compromised; package removal alone is not recovery.

  3. 3

    Handle persistence safely. Inspect affected hosts for the reported token monitor and other persistence. Coordinate isolation and removal with incident responders before revoking a GitHub token that the monitor may be checking.

  4. 4

    Rotate and trace spread. After the monitor is neutralised, replace potentially exposed GitHub, npm, cloud, SSH, Kubernetes, Vault and application secrets. Audit unexpected package publishes, public repositories and changes under .claude or .vscode.

An agent sandbox does not protect the machine that installs its SDK

  • The install hook inherits the permissions of the installing user. Map the secrets and publishing rights available to that user or runner.
  • A clean application build is not proof of a clean developer workstation; the hook may run before any test or import.
  • The researchers' indicators are useful starting points, but account activity and host evidence determine whether credential theft or propagation occurred in your environment.

This is an active investigation. Confirm affected versions, persistence details and recovery steps against the linked researcher updates before taking disruptive action.