DependencyWatch.io
FeedSolutionsSubmitScan your lockfile
Feed
CriticalCompromisePublished 8 Oct 20261 package · 1 version

`tensorlake` npm maintainer-account compromise - malicious `0.5.144` published one patch above the real `0.5.143` latest and quarantined by npm security

Summary

On 2026-10-08 a malicious tensorlake@0.5.144 was published to npm, exactly one patch above the real TensorLake AI 0.5.143 latest. The upstream package is the official TensorLake AI document-ingestion / sandbox CLI/SDK with 100 legitimate releases across four maintainers; 0.5.144 was removed from the registry and GHSA-rqxj-g25x-4v9v flagged the version as malware. Pattern is a maintainer-account or publish-credential compromise.

maintainer-takeoveraccount-takeovercredential-theft
Incident type
Compromise. A legitimate, already-used package, maintainer account, CI pipeline, or release tag was hijacked and a malicious version was published under a name people already depend on.
Detected by
GitHub Advisory Database · npm security
Also known as
tensorlake 0.5.144 npm compromise · TensorLake AI npm maintainer compromise
Ecosystems
npm
Packages tracked
1

What happened

On 2026-10-08 a malicious release of tensorlake@0.5.144 was published to the public npm registry and almost immediately quarantined by npm security. The GitHub Advisory Database tracks the incident as GHSA-rqxj-g25x-4v9v ("Malware in tensorlake"), published 2026-10-08 with CWE-506 Embedded Malicious Code.

The affected package is not a typosquat or new malicious lure: tensorlake is the official TensorLake AI npm CLI/SDK by tensorlake.ai, with 100 published releases dating to 2026-04-05 (0.4.39), four maintainers (diptanuc, calavera, sumit-tensorlake, cooleel), and tarball-shipped CLI binaries tl, tensorlake, function-executor, tensorlake-deploy, tensorlake-create-sandbox-image.

The maintainer-account-compromise fingerprint

The malicious version 0.5.144 sits one patch above the real latest 0.5.143. This is the canonical fingerprint seen in every maintainer-account or publish-credential compromise on npm since Shai-Hulud (2025-09): the attacker publishes the next patch so that any consumer with a floating ^0.5 or ~0.5.143 constraint resolves into the malicious tarball on the next install, while leaving latest sitting at a version only one tick higher than yesterday's legitimate release (minimising the audit signal for a hurried maintainer scrolling npm web).

At time of writing https://registry.npmjs.org/tensorlake/0.5.144 returns version not found: 0.5.144 - npm security has pulled the tarball. The GHSA advisory is boilerplate CWE-506: no IOC, no SHA-256, no vendor write-up. Based on the operator profile (npm maintainer compromise, patch-above-latest, dev-tooling package wiring CLIs via bin: fields that execute at node_modules/.bin), the plausible payloads are credential-stealing worms in the shape of Trinitite (2026-08-28), Mastra (2026-06) or Jscrambler (2026-07), or install-time RCE via postinstall on a CLI binary.

Scope

Any CI run or developer install that resolved tensorlake between the moment of first publish on 2026-10-08 and the npm takedown is in scope. Teams running npm install tensorlake, pnpm install tensorlake, tensorlake deploy in CI, or any auto-upgrade bot (Dependabot, Renovate) that bumped tensorlake from ~0.5.143 into 0.5.144 during that window should treat the installer host as potentially executed-against until an IOC-level analysis clears the version.

Why this gets its own incident file

This compromise is split out of the daily 2026-10-08 GHSA sweep because it meets the "sweep carve-out" criterion: a hijacked package that real projects already depend on (official TensorLake AI tooling with 100 releases and four maintainers) rather than a typosquat, dep-confusion probe, or CWE-506 boilerplate takedown. Severity is critical because the reach is confirmed to the full TensorLake AI consumer base, even though the published payload analysis has not yet landed.

Related tracked activity

Affected packages (1)

These are usually pulled in as transitive dependencies rather than installed directly. Check your whole tree at once - it runs in your browser and nothing is uploaded.

Check package-lock.json

Impact

  • A malicious npm release of tensorlake@0.5.144 was published to the public npm registry on 2026-10-08 and quarantined by npm security the same day. The malicious tarball has been removed - https://registry.npmjs.org/tensorlake/0.5.144 now returns version not found: 0.5.144 - but any CI run or developer install that resolved the package between the moment of first publish and the npm takedown fetched the malicious tarball
  • The upstream package is legitimate. tensorlake is the official TensorLake AI document-processing / sandbox CLI and SDK (TensorLake AI, tensorlake.ai), with 100 published releases dating back to 0.4.39 (2026-04-05) and four maintainers: diptanuc (Diptanu Choudhury), calavera (David Calavera), sumit-tensorlake and cooleel. The npm package ships the tl, tensorlake, function-executor, tensorlake-deploy and tensorlake-create-sandbox-image CLI binaries - any CI that invokes tensorlake deploy or runs a sandbox image build pulls a tarball of this name. Latest real version at time of writing is 0.5.143
  • The malicious version slot 0.5.144 sits one patch above the real latest 0.5.143 - the canonical fingerprint of a maintainer-account or publish-credential compromise. In the Shai-Hulud and Mastra-wave compromises of 2025-2026 the attacker consistently chose the next patch version so that any consumer with a floating ^0.5 or ~0.5.143 constraint would upgrade into the malicious tarball on the next install. The maintainer's own semver did not jump, and the version was never used in a legitimate release by the real maintainers
  • No published payload analysis yet. GHSA-rqxj-g25x-4v9v is a CWE-506 "Embedded Malicious Code" boilerplate advisory with no IOCs or SHA-256 - the tarball was pulled before third-party vendor analysis landed. Given the operator profile (npm maintainer compromise, patch-above-latest, dev-tooling package with install-time binary wiring), the most likely payloads based on prior incidents in the same shape (Mastra 2026-06, Jscrambler 2026-07, Trinitite 2026-08-28) are credential-stealing worms (npm/GitHub/cloud token harvest, GitHub repo exfil) or install-time RCE via a postinstall hook on the installed CLI binaries
  • Downstream exposure is broad. Any team that runs npm install tensorlake, pnpm install tensorlake, or any workflow that upgrades tensorlake from ~0.5.143 or ^0.5 on 2026-10-08 before the npm takedown would have resolved the malicious tarball. Any CI runner that executed the tl / tensorlake CLI from the tarball post-install is in-scope for post-exploitation. Internal registry mirrors (Nexus, Artifactory, Verdaccio) that cached the malicious tarball between publish and takedown continue to serve it until explicitly flushed

What to do

  1. 1Grep every lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock), node_modules/tensorlake/package.json, and any mirrored registry cache for the exact string 0.5.144 on the tensorlake package name. Also grep for any tensorlake-* CLI binary resolved from a tarball with that version in its path
  2. 2Pin tensorlake to 0.5.143 or an earlier verified-good release, with an exact-version constraint (not ^0.5.143 or ~0.5.143 - those will re-admit a future malicious 0.5.144 republish if an attacker re-attempts the hijack). Rebuild lockfiles after the pin and re-run npm ci / pnpm install --frozen-lockfile to guarantee the compromised tarball is evicted from every workspace. If an internal registry mirror caches the public tarball, flush its tensorlake@0.5.144 entry explicitly
  3. 3If any developer or CI runner installed tensorlake@0.5.144: treat that machine as fully compromised until an IOC-level analysis clears it. Rotate every credential reachable from the environment, starting with npm auth tokens (npm token revoke <hash> for every token the user owns), GitHub PATs / fine-grained tokens / SSH keys under the same user, then cloud-provider CLI credentials (aws configure, gcloud auth, az login), then any secret exported into the affected job`s environment. Audit every other npm package the affected developer publishes for a trojanised republish during the same window - a worm payload in the same shape as Trinitite (2026-08-28) would attempt to auto-publish to every package the harvested token can reach
  4. 4For the TensorLake AI maintainers: when the account is recovered, enable mandatory 2FA on every maintainer npm account under the tensorlake.ai domain, migrate publishing off long-lived npm tokens to npm OIDC trusted publishing (CI-only, no human token in the publish path), and audit CI workflow permissions for any id-token: write scope held at workflow level rather than step level. Review the GitHub repository`s GitHub Actions logs around 2026-10-07 / 2026-10-08 for any unauthorised run that minted an npm publish token, and check for any new attacker-created repository under maintainer GitHub accounts matching the Trinitite / Shai-Hulud exfil pattern
  5. 5Monitor for a wave-2 republish. The pattern on prior maintainer-account compromises is a follow-up publish of a higher patch version (0.5.145, 0.5.146) within hours or days if the credentials are not yet rotated. Set a CI gate that blocks tensorlake@>0.5.143 until the TensorLake AI maintainers publish a confirmed clean release and the GHSA advisory is retracted or scoped
  6. 6Watch for IOCs typical of this operator family: new GitHub repositories under TensorLake AI maintainer accounts with randomly-generated names and credential-bundle commits, outbound traffic from CI runners to unexpected GitHub repositories, and any npm publish events from the TensorLake AI maintainer accounts that do not correspond to a maintainer-authored release commit

References

Back to feedSubmit a correction
npm-2026-10-08-tensorlake-maintainer-compromise