The Worm Beneath the Code: How Shai-Hulud Turned a Trusted npm Package Into a Supply Chain Tunnel
Every software ecosystem resembles a city.
Developers construct applications like buildings, dependencies form their foundations, repositories supply the materials, and automated pipelines transport those materials from one construction site to another.
The entire city depends on trust.
A developer installs a package. A build system executes its installation scripts. A release pipeline publishes a new version. Other projects consume it, assuming the material arriving from a familiar supplier is safe.
But beneath one of those foundations, something was moving.
On October 8, 2026, researchers disclosed that the tensorlake npm package had been compromised by malware associated with the ChainDrop / Shai-Hulud supply chain campaign.
The malicious release did not simply introduce a backdoor into one application.
It carried a credential-stealing, self-propagating worm capable of exploiting the trust relationships connecting developers, repositories, cloud environments and automated publishing systems.
And like a giant sandworm traveling beneath an unsuspecting city, its greatest advantage was that nobody needed to see it moving for the damage to spread.
Phase 1 — The Worm Enters Through the Foundation
The first signs of the intrusion appeared inside the legitimate Tensorlake development repository.
According to StepSecurity, malicious files were pushed to the main branch of tensorlakeai/tensorlake under a maintainer’s name.
The first rogue commit occurred on October 7, 2026, at 01:20 UTC.
The following day, the repository’s release workflow published tensorlake version 0.5.144 to npm.
From the outside, the package appeared to have followed the expected construction process.
The materials came from the established supplier.
The release machinery performed its usual work.
But something had been placed inside the foundation before the shipment left the warehouse.
The worm had entered the supply chain through a trusted release path.
Phase 2 — The Ground Opens During Installation
The malicious package contained a preinstall hook.
That detail mattered because npm installation hooks can execute code as part of the dependency installation process.
The developer did not need to deliberately launch a suspicious executable.
Installing the dependency could trigger the malicious sequence.
The hook launched package/lib/setup.mjs, an obfuscated JavaScript loader that activated the main payload, package/lib/Math_Symbol.js, through the Bun runtime.
Imagine a construction crew lowering a new foundation block into place.
The moment the block touches the ground, something buried inside it wakes up.
The workers believe they are assembling the building.
But the installation itself has activated the creature beneath them.
That was the attacker’s advantage: the malicious code was positioned inside a workflow developers routinely trusted.
Phase 3 — The Worm Begins Hunting for Keys
Once active, the malware searched its surroundings for credentials and sensitive information.
Its targets extended well beyond a single npm authentication token.
The worm could harvest:
npm and GitHub tokens
AWS credentials and secrets
HashiCorp Vault and Kubernetes credentials
SSH keys and .env files
Cryptocurrency wallets and messaging application data
Configuration and MCP files associated with Claude, Cursor, Kiro, Windsurf and Zed
It also deployed HackBrowserData to collect browser-related information.
In the city above, every building had its own doors.
The cloud infrastructure had keys.
The repositories had keys.
The deployment pipelines had keys.
The AI development environments held configurations that could expose additional information.
The worm was not trying to break every lock individually.
It was collecting the keys from beneath the buildings.
And because developer machines and automated environments frequently have access to multiple systems, compromising one execution context could expose secrets belonging to several others.
Phase 4 — The Worm Tunnels Into Neighboring Buildings
Shai-Hulud was not designed merely to steal and disappear.
It could propagate.
After obtaining access to a victim’s publishing identity, the worm enumerated npm packages associated with that identity.
It could then prepare compromised releases, generate Sigstore provenance and republish infected package versions.
This transformed stolen credentials into a mechanism for further distribution.
A compromised developer account could become a route into additional packages.
Those packages could subsequently reach other developers and automated build environments.
Each newly infected environment might contain more credentials.
And those credentials might open still more doors.
The sandworm was no longer confined to its original foundation.
It was digging tunnels between buildings, turning the connections that made the software city efficient into pathways for infection.
Researchers also identified strings referencing a fake Copilot/Dependabot workflow, suggesting the malware could plant malicious GitHub Actions workflows.
The disguise was especially dangerous because automated development workflows often appear to be routine maintenance activity.
Phase 5 — The Worm Builds Hidden Chambers
Removing the infected dependency was not necessarily enough to eliminate the threat.
The malware included persistence capabilities designed to survive beyond the original installation.
StepSecurity reported that it wrote configuration files such as:
.claude/settings.json
.vscode/tasks.json
These files could cause malicious behavior to execute again when someone opened the affected project using Claude Code or Visual Studio Code.
The distinction is important.
The original package might be removed.
The compromised dependency might disappear from the manifest.
But malicious instructions could remain inside the development environment.
The construction crew might remove the contaminated foundation block and declare the building safe.
Meanwhile, the worm had already carved a chamber beneath the floor.
The next time a developer opened the project, the hidden mechanism could reactivate.
This is why recovering from a supply chain compromise requires investigating what the malicious package executed, not simply uninstalling the package itself.
Phase 6 — The Stolen Secrets Travel Through Underground Routes
The worm also employed multiple exfiltration mechanisms.
Its primary destination was an attacker-controlled endpoint at iseekaigogo[.]com:443/router.
If that route failed, the malware could consult an Ethereum smart contract to resolve its command-and-control destination.
GitHub provided another fallback.
The malware could stage encrypted stolen information in a public repository bearing the description:
Shai-Hulud: Here We Go Again.
It also searched signed GitHub commits for a specific marker, thebeautifulmarchoftime, and checked for signatures associated with an embedded RSA key.
The purpose of this infrastructure was resilience.
Blocking one route did not necessarily stop the information from leaving.
The worm could look for another tunnel.
One passage led directly to the attacker’s server.
Another relied on blockchain-hosted information.
A third used a legitimate code-hosting platform as a staging location.
The city had multiple underground exits, and the worm knew where they were.
Phase 7 — The Worm Threatens to Collapse the Building
One of the most aggressive components involved a stolen GitHub token.
The malware included a so-called hostage token mechanism.
A PowerShell monitor repeatedly contacted api.github.com/user using the compromised token to determine whether it remained valid.
If the victim revoked that token, the monitor could execute an attacker-supplied handler through PowerShell’s Invoke-Expression.
The associated destructive behavior was designed to wipe the victim’s home directory.
In other words, revoking a stolen credential could potentially trigger retaliation if the malicious monitor remained active.
Imagine discovering that the worm has stolen the keys to your building.
You change the locks.
But beneath the foundation, the creature has left a mechanism designed to destroy the structure when it realizes the keys no longer work.
That is what made this capability particularly concerning.
Credential revocation remained necessary, but incident response also had to account for the possibility of destructive persistence.
The existence of this capability does not establish that it was triggered against a particular Tensorlake victim.
It does, however, demonstrate the destructive potential built into the malware.
Phase 8 — The Worm Reaches the AI District
The Tensorlake compromise also reflected a broader evolution in supply chain targeting.
ChainDrop had previously been associated with compromises involving hundreds of npm packages, including Keyv and Cacheable, and earlier Shai-Hulud variants.
But Tensorlake brought the threat directly into software used for AI applications, sandboxes and cloud services.
The malware’s interest in configuration files associated with Claude, Cursor, Kiro, Windsurf and Zed reinforced that direction.
AI development environments are increasingly connected to repositories, local files, tools and external services.
Those connections can make them valuable targets.
The worm did not need to understand the intelligence of an AI assistant.
It needed access to the files, credentials and permissions surrounding it.
The newest district in the software city had been built on familiar foundations: dependencies, automation and trusted identities.
And the worm had learned to tunnel beneath those foundations too.
Phase 9 — Stop the Worm Before Rebuilding the City
By the time researchers disclosed the compromise, malicious version 0.5.144 was no longer available for download from npm.
But removing the package from the registry could not undo installations that had already occurred.
Organizations that installed the affected version needed to investigate the potential exposure of their development environments.
The response should include removing the malicious dependency, identifying affected systems, examining installation activity and persistence mechanisms, and rotating potentially compromised credentials.
Particular attention should be given to npm publishing tokens, GitHub credentials, cloud secrets, CI/CD environments, Kubernetes access, Vault credentials and SSH keys.
Repositories should also be inspected for unauthorized GitHub Actions workflows and suspicious Claude Code or VS Code configuration files.
Published package versions should be reviewed for unexpected releases.
Because a self-propagating worm changes the scope of the investigation.
It is not enough to determine whether the original building was compromised.
Defenders must discover which other buildings were connected to it, which keys were stolen and where the worm may have tunneled next.
Phase 10 — The City Was Built on Trust
The Tensorlake incident illustrates a fundamental weakness in modern software supply chains.
A package does not need to look suspicious to become dangerous.
A release does not need to come from an unfamiliar repository.
A malicious script does not need to wait for a developer to execute it manually.
Sometimes the attacker reaches the trusted source itself.
And once that happens, the ordinary machinery of software development can become part of the intrusion.
The repository accepts the changes.
The release workflow publishes the package.
The developer installs the dependency.
The installation hook executes.
The worm collects credentials.
Those credentials open new repositories.
New compromised packages enter circulation.
The cycle can continue.
Each step exploits a relationship that was supposed to make development faster and more reliable.
The real lesson is not that dependencies should never be trusted.
It is that trust must be continuously verified, especially where code execution, credentials and automated publishing intersect.
Because the most dangerous threat to a software city may not be an attacker standing outside its walls.
It may be something already buried beneath the foundations.
Waiting for the next installation.
Waiting for the next release.
Waiting for the next set of keys.
The worm did not need to conquer the city from above.
It only needed to make the entire supply chain tremble from below.
The Hacker News
Comentarios