New CanisterWorm Steals npm Tokens and Spreads Through Compromised Publisher Accounts

A new wave of supply chain attacks is hitting the npm ecosystem through a self-propagating malware campaign known as CanisterWorm.

The threat, linked to a group tracked as “TeamPCP,” compromises legitimate publisher namespaces and pushes poisoned package versions, effectively turning trusted developer tools into silent delivery mechanisms for credential-stealing code.

CanisterWorm first came to public attention through early reports from security researchers at Socket and Endor Labs, who traced a recurring pattern of malicious package updates across multiple npm publisher accounts.

The malware is carefully concealed inside what appear to be routine SDK version bumps, making it easy for developers to install it without raising any suspicion.

JFrog researchers identified new, previously unreported compromised package versions tied to the CanisterWorm attack, extending the known scope of the campaign well beyond what earlier disclosures had covered.

Their continuous monitoring pipeline surfaced additional affected versions across multiple namespaces — including packages maintained under @emilgroup and @teale.io — that had gone undetected in prior public reports.

The impact of a successful infection goes far beyond a single machine. Once a developer installs one of the tainted packages, CanisterWorm drops a Python backdoor onto the host, begins harvesting npm authentication tokens, and uses those credentials to autonomously spread itself to every package the compromised developer maintains.

This chain-reaction behavior means one affected developer account can become a launchpad for poisoning dozens of downstream packages, putting a wide range of dependent projects and their users at immediate risk.

What makes CanisterWorm particularly difficult to contain is how naturally it blends into normal development workflows.

By hiding behind version updates and leveraging decentralized infrastructure for command communication, it sidesteps the traditional indicators that most security tools look for, quietly expanding its reach before anyone notices something is wrong.

Inside the Worm’s Infection Chain

The infection process begins the moment a developer runs npm install on a compromised package.

A malicious postinstall hook embedded inside the package.json file executes automatically and silently drops a Python backdoor onto the host system without any visible warning.

On Linux machines, the worm then registers a persistent background service named pgmon through systemd, ensuring it stays active and survives system reboots.

Once established, the backdoor continuously polls an Internet Computer Protocol (ICP) canister — a decentralized, blockchain-hosted endpoint — that acts as a dead-drop command-and-control server.

This design makes the malicious traffic blend naturally with regular web requests, significantly hampering detection by network monitoring tools.

Secondary payloads retrieved through this channel are written to /tmp/pglog, while the worm tracks its execution state inside /tmp/.pg_state.

The most dangerous phase of the attack is the autonomous spreading routine. The malware scans .npmrc files across the project directory, the user’s home folder, and system-wide configuration paths, searching for _authToken values.

It also reads the NPM_TOKEN and NPM_TOKENS environment variables. With those stolen credentials, a built-in deploy.js script queries the npm registry, locates every package the victim maintains, increments each one’s patch version number, and publishes the tainted update automatically.

Known Compromised Packages:-

Anyone running any of the identified compromised package versions should treat their environment as already infected. Developers must immediately rotate all npm publishing tokens stored in .npmrc files, environment variables, and CI/CD pipeline secrets.

On Linux, the pgmon service must be stopped and disabled using systemctl, with its associated service files and directories removed entirely.

The temporary files /tmp/pglog and /tmp/.pg_state must be deleted. Affected node_modules directories should be purged and rebuilt from scratch using verified, safe package versions.

Developers whose tokens were stolen must manually unpublish the compromised package versions from the npm registry, since simply publishing a newer version does not protect downstream users who may still install the infected release.

Running npm config set ignore-scripts true globally prevents postinstall hooks from firing silently on future installs, serving as a practical defensive measure against this class of supply chain attack.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.