Trivy Supply Chain Attack Expands as CanisterWorm Spreads Across 47 npm Packages
A supply chain attack that first hit Aqua Security’s Trivy ecosystem has now widened into a more dangerous second-stage campaign, with a newly documented worm dubbed CanisterWorm compromising 47 npm packages and turning infected developer environments into fresh propagation points. The latest findings suggest the attackers moved quickly from poisoning a trusted security tool to building a self-spreading infection chain designed to steal npm tokens, publish malicious package updates, and expand across downstream software ecosystems.
The development marks a serious escalation because the attack is no longer limited to a one-time credential theft or a single malicious release. In its newer form, the malware can spread from one compromised development environment to another, creating the kind of chain reaction that makes software supply chain incidents especially difficult to contain once they escape the original blast zone.
From compromised Trivy releases to a wider npm outbreak
Researchers say the latest wave follows directly after the compromise of malicious Trivy, trivy-action and setup-trivy releases that contained credential-stealing code. Aqua Security has told users to pin to safe versions, rotate secrets immediately if they ran the compromised releases, and block known attacker infrastructure. That advice now looks even more urgent given what came next.
The follow-on campaign appears to have targeted 47 npm packages in total, including 28 packages under the @EmilGroup scope, 16 under @opengov, plus @teale.io/eslint-config, @airtm/uuid-base32, and @pypestream/floating-ui-dom. The package count matters because it shows the attackers were not just experimenting. They were building reach.
Security researchers suspect the same threat activity sits behind both stages of the operation. That continuity suggests a deliberate campaign rather than a loosely connected copycat effort, with the Trivy compromise serving as a stepping stone into a broader developer-focused malware push.
How CanisterWorm infects developer systems
The infection chain begins with a malicious postinstall hook embedded in the npm package. Once a victim installs the package, that hook runs automatically and launches a loader, which then drops a Python backdoor onto the system. From there, the malware contacts a dead drop resolver hosted through an Internet Computer Protocol canister to fetch the next-stage payload location.
That design is unusual and important. Researchers say this is the first publicly documented case of an ICP canister being used specifically to retrieve command-and-control infrastructure for malware. Because the dead drop sits on decentralized infrastructure, it is more resistant to conventional takedown efforts than a normal hardcoded domain or straightforward C2 server.
The malware then polls the canister roughly every 50 minutes using a spoofed browser user agent, retrieves a URL in plaintext, and downloads the next binary from there. If the URL points to YouTube, the implant stays effectively dormant. If the attacker switches the canister to a real payload location, infected systems pull down the new binary on their next check-in.
Persistence, stealth and decentralized control
Once established, the malware sets up persistence through a user-level systemd service that disguises itself as PostgreSQL tooling under the name pgmon. The service is configured to restart automatically if terminated, which gives the attacker a durable foothold even if defenders remove a running process but miss the persistence layer.
The use of a decentralized dead drop also gives the operator unusual flexibility. Researchers say the attacker can swap the URL served by the canister at any time, allowing every infected host to fetch a new payload without updating the implant itself. In effect, the attacker can arm, disarm, or repoint the botnet-like infrastructure from one central control point while leaving the malware unchanged on each host.
That architecture is one reason the worm stands out. It is not just a malicious package. It is a persistent loader framework with remote update capability, hidden in places developers often trust by default.
Why the self-propagating version changes the threat level
The first observed wave relied on a separate deploy.js utility that the attacker had to run manually using stolen npm tokens. That script was designed to enumerate publishable packages tied to the stolen credentials and push malicious versions to the registry programmatically. It was already dangerous, but it still required active operator involvement.
The newer CanisterWorm variant, seen in @teale.io/eslint-config versions 1.8.11 and 1.8.12, goes further. Researchers say the package now bakes the token-harvesting and propagation logic directly into index.js. During the postinstall phase, it looks for npm authentication tokens on the victim machine and then launches the publishing logic as a detached background process.
That is the moment the incident becomes qualitatively worse. A developer or CI runner that installs the package and has accessible npm tokens can unintentionally become a propagation node, infecting its own packages and exposing downstream users in turn. It moves the operation from compromised credentials being misused by an attacker to malware itself creating fresh publisher compromises.
A warning for CI pipelines and package maintainers
This attack is a sharp reminder that developer machines and CI systems are now prime targets, not just because they hold source code, but because they often hold registry tokens, signing material, and automation privileges capable of contaminating entire release chains. A single infected build environment can become the bridge between one malicious package and dozens more.
Aqua Security has already advised anyone who ran the compromised Trivy components to rotate pipeline secrets immediately. That is now only the starting point. Teams also need to review npm publishing tokens, inspect recent package releases, audit postinstall behavior in dependencies, and lock down registry permissions wherever possible.
CanisterWorm is a sign of where supply chain attacks are heading next. The objective is no longer only to backdoor a popular package or steal secrets from a build job. It is to create malware that can live inside the software supply chain itself and spread using the trust relationships developers rely on every day.