An AI Platform's npm Package Was Hijacked to Steal Credentials: What to Check Today in Your JavaScript Projects

On Thursday, October 8, 2026, at 01:12 UTC (8:12 p.m. Wednesday in Ecuador), version 0.5.144 of the tensorlake package appeared on npm. It is the TypeScript SDK of Tensorlake, a platform for building AI agents. It was not a normal update: it carried a variant of the Shai-Hulud worm, malware that steals developer credentials and copies itself into other packages. It was reported, with matching details, by Socket, Aikido and Endor Labs.

If your team does not use tensorlake, this case still matters to you: it is the same kind of attack that has already hit other popular packages, and it will happen again.

What happened

According to Aikido and GBHackers, on October 7 the attacker made commits to the project's GitHub repository under a maintainer's identity. The next day, the project's own release workflow pushed the infected version to npm. Socket and Endor Labs agree that the most likely cause is a compromised maintainer account: the attacker did not have to break npm, just walk in through a trusted person's door.

Socket says it detected the package 11 minutes after it was published. Aikido and Endor Labs report that the version has been removed from the npm registry, and Endor Labs states that 0.5.143 and earlier do not contain the malicious code.

Why it is dangerous even if you never use the package in your code

The malware is triggered by a preinstall script: it runs during npm install, before anyone imports or runs anything. All it takes is for version 0.5.144 to have been installed on a laptop or a continuous integration (CI) server. Once inside, according to the published analyses:

• It hunts for credentials: npm and GitHub tokens, SSH keys, AWS, Google Cloud and Azure credentials, Kubernetes and Docker configuration, .env files and CI/CD secrets. Socket adds that it also looks for the configuration of AI coding tools.
• It steals cryptocurrency: it goes through wallet extensions in the browser.
• It spreads: with stolen npm tokens, it publishes infected versions of other packages the victim maintains. One infected developer can thus infect their own users.
• It has a "dead man's switch": Aikido, Socket and GBHackers warn that it can wipe data on the infected machine if it detects that the token it uses was revoked. That is why the cleanup order matters.

How to tell if you were affected

1. Look for the package in your projects: run npm ls tensorlake in each repository, and search for tensorlake and 0.5.144 in your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock).
2. Check your CI: the logs of jobs that installed dependencies since October 8, especially those that do not use a lockfile or that update versions automatically.
3. Check your accounts: versions of your npm packages that nobody on your team published, and new repositories in your GitHub account or organization that nobody created.

If you installed it: order matters

1. Isolate the machine or runner and treat it as compromised, as Socket, Aikido and GBHackers recommend.
2. Remove the malware's persistence first, then revoke tokens. Socket flags this as critical: if you revoke first, the switch may wipe the user's directories. If you have no experience with this, get help before touching anything.
3. Rotate every credential that machine had access to: npm, GitHub, SSH keys, cloud, databases and everything in .env files.
4. Pin the clean version (0.5.143 or earlier, according to Endor Labs) or wait for a new release verified by the project, and rebuild from a trusted source.

How to prevent the next one

• Always use a lockfile and install with npm ci in CI, so no version nobody reviewed gets in.
• Disable install scripts where you can, with npm install --ignore-scripts or ignore-scripts=true in .npmrc, as Endor Labs suggests, and enable them only for packages that truly need them.
• Least-privilege, short-lived tokens, never stored in plain text on laptops. Turn on two-factor authentication on npm and GitHub for the whole team.
• Turn on dependency alerts in your repository so you find out quickly when a version is flagged as malicious.

What it means for your business

If your company commissions software, this kind of attack does not hit your system through a bug in your code, but through the tools of whoever builds it. It is worth asking your team or development vendor three questions: do you use lockfiles and review dependency updates? Where are production credentials stored, and who has them on their laptop? And what would you do in the first hour if a dependency turned out to be infected? If the answers take a while, you have work to do.

How We Approach It at SimCodec

At SimCodec we build custom software with pinned dependencies, CI that installs without unnecessary scripts and credentials kept off team laptops. We also review existing projects: dependency inventory, npm and CI configuration, and a response plan in case something goes wrong.

If you want to review your JavaScript projects or your vendor's, write to us or call our AI assistant Cyntia at +593 99 726 6838.