In 2026, Node.js developers suddenly found themselves facing a threat appearing inside the npm registry – CanisterWorm. More notably, this worm could turn developers’ computers, if infected, into new propagation points, steal npm tokens, and republish node packages without the authors’ consent. This attack affected dozens of packages. If any software development team accidentally installed these Node packages at that time, they may have a backdoor in their system. Thanks to security researchers tracing the attack chain, the root cause was linked back to Trivy, a legitimate security scanner that had itself been compromised in a supply-chain attack. Let’s learn how this attack occurred!
1. What is CanisterWorm?
1.1. History of Computer Worms
Computer worms are not new. They have existed for decades, dating back to the early days of the Internet. A computer worm is a type of malware capable of automatically infecting other computers and reproducing itself across infected systems. Over the years, numerous notorious worms have caused widespread disruption and damage, from stealing sensitive data to causing financial losses, especially when it can carry other ransomware, backdoor or data stealers with it. Below are some notable worm-based incidents that illustrate how their propagation techniques and payloads have evolved over time:
1.1.1 Morris Worm — 1988
The Morris Worm, released in 1988, was one of the earliest major Internet worms and demonstrated that self-propagation could exploit multiple paths at once. It targeted Unix systems by abusing vulnerabilities in the fingerd service, exploiting Sendmail’s debug mode, and taking advantage of trusted remote-access mechanisms such as rsh and rexec. It also attempted to guess users’ passwords using predictable variations, a built-in list of common passwords, and dictionary words. Unlike later worms that carried data stealers or ransomware, Morris was not designed to steal or destroy files; its major impact came from a flaw in its replication logic that caused excessive reinfection and consumed CPU, memory, and network resources, eventually making many infected systems unusable.
1.1.2. Conficker — 2008
The Conficker Worm, first discovered in 2008, demonstrated how a worm could combine multiple propagation techniques to spread rapidly across Windows networks. Its primary attack vector was MS08-067, a critical vulnerability in the Windows Server service that allowed remote code execution. Later variants expanded propagation by accessing ADMIN$ network shares using weak passwords and spreading through removable drives via AutoPlay. Conficker also disabled security services, blocked access to security-related websites, and could download additional files, making it more than a simple self-replicating program. At its peak, Conficker was estimated to have infected millions of computers worldwide, illustrating how an unpatched vulnerability combined with weak credentials and removable media could turn a single compromised machine into a large-scale infection platform.
1.1.3. WannaCry — 2017
The WannaCry ransomware, which emerged in 2017, demonstrated how traditional worm propagation could be combined with ransomware to create a highly disruptive attack. It exploited the EternalBlue vulnerability in Windows SMBv1 (CVE-2017-0145), addressed by Microsoft through security update MS17-010, allowing the malware to remotely compromise vulnerable, unpatched Windows systems and then scan for additional victims across local networks and the Internet. Once a system was infected, WannaCry encrypted files and demanded a ransom, turning the worm’s rapid self-propagation into a mechanism for multiplying the ransomware’s impact across entire networks. This marked a significant evolution from earlier worms such as Morris and Conficker: the worm no longer merely destroyed a computer; it became the delivery mechanism for a financially motivated ransomware attack.
1.2. CanisterWorm
CanisterWorm represents a different generation of worm, shifting propagation from vulnerable network services to the software supply chain itself. Emerging in 2026, it used npm publishing credentials stolen during the Trivy compromise to infect legitimate packages; when a developer installed an infected package, its malicious postinstall code could harvest npm credentials from that environment and automatically publish itself to other packages that the account was authorized to modify, turning each new victim into another propagation point. Unlike Morris, which spread through network-service vulnerabilities, or WannaCry, which combined network exploitation with ransomware, CanisterWorm abused developer trust, package publishing privileges, and automated software distribution.
2. How did it spread?
CanisterWorm’s propagation mechanism was like so:
1. Initial compromise: The attack begins with a compromised CI/CD environment and stolen credentials, including npm publishing tokens. In the campaign associated with the Trivy compromise, these credentials provided access to legitimate npm publishing accounts.
2. Malicious package publication: Using the stolen npm token, CanisterWorm identifies packages that the compromised account is authorized to publish, increments their versions, injects malicious installation logic, and publishes the modified packages. The packages remain legitimate-looking because they are distributed through the normal npm ecosystem.
3. Victim installs the package: When a developer or CI/CD system installs an infected package, its npm installation script executes automatically. This gives the worm code execution inside the new environment.
4. Harvest credentials: CanisterWorm searches the newly infected environment for npm authentication material, including .npmrc files and npm tokens. It can also collect other credentials and cloud secrets that may be useful for further compromise.
5. Turn the victim into a publisher: If valid npm credentials are discovered, the worm uses them to authenticate to npm and enumerate packages that the compromised account can publish. It then repeats the same process: modify packages, increase their versions, and publish infected releases.
6. Repeat the cycle: Users install the newly infected packages, creating additional compromised environments. Each environment may expose another set of credentials, allowing the worm to reach more packages and developers. The result is a self-propagating loop: infect → steal credentials → publish infected packages → infect new environments → repeat.
3. How To Defend Against Supply Chain Worms ?
Different from traditional software-based worms, a supply-chain worm is not easily detected by conventional antivirus software because its existence is not an executable file but rather a normal installation step in a legitimate package, delivered via a trusted mechanism. Therefore, defending against CanisterWorm requires protecting the entire software supply chain rather than relying solely on antivirus software.
3.1. Protect NPM Publishing Credentials
The first priority is to protect npm publishing credentials. CanisterWorm can search for npm authentication tokens and use stolen credentials to identify packages that an account can publish, inject malicious code, and release new versions. Publishing tokens should therefore must have the minimum permissions (Least Privilege Principle), be short-lived where possible, and never be unnecessarily exposed in source code or CI/CD environments.
3.2. Restrict CI/CD Environments
Least Privilege Principle should be applied in CI/CD environments as well. Build runners should receive only the secrets required for their specific tasks, while publishing privileges should be separated from ordinary build and testing operations. Unexpected package publications, version changes, or publishing activity should trigger investigation.
Organizations should also control npm lifecycle scripts, particularly preinstall, install, and postinstall scripts, because malicious packages can use these mechanisms to execute code automatically during installation. Where lifecycle scripts are not required, they can be disabled, while packages introducing unexpected installation behavior should receive additional scrutiny.
3.3. Monitor Access to Credential Files
Security monitoring should pay attention to processes accessing files such as .npmrc, SSH configuration and key files, cloud credential files, and CI/CD secret locations. Access to these files is not necessarily malicious, but it becomes highly suspicious when a package installation process, unfamiliar Node.js process, shell script, or recently introduced dependency attempts to read multiple credential stores in a short period of time.