New Exploit Targets npm Tokens Via Compromised Publisher Accounts

A sophisticated malware campaign dubbed CanisterWorm is exploiting the npm ecosystem, a critical hub for JavaScript developers, by compromising legitimate publisher accounts to distribute malicious code. This supply chain attack, attributed to a threat actor group known as “TeamPCP,” stealthily injects credential-stealing malware into widely used packages, turning trusted development tools into vectors for theft. Security researchers from Socket, Endor Labs, and JFrog have been instrumental in uncovering and tracking the evolving scope of this threat.

Recent findings by JFrog researchers have identified new, previously unreported compromised package versions linked to CanisterWorm, significantly expanding the known impact of the campaign. These poisoned packages often appear as routine SDK version updates, making them difficult for developers to distinguish from legitimate software. The malware’s insidious nature lies in its ability to spread autonomously, turning a single compromised account into a launchpad for poisoning numerous downstream projects.

Inside the Worm’s Infection Chain

The CanisterWorm attack chain begins when a developer unknowingly installs a tainted npm package. A malicious `postinstall` hook, embedded within the `package.json` file of the compromised package, executes automatically upon installation. This hook silently deploys a Python backdoor onto the host system without raising any immediate alerts. On Linux systems, the malware further establishes persistence by registering a background service named `pgmon` via `systemd`, ensuring it remains active even after system reboots.

Once installed, the Python backdoor communicates with a command-and-control (C2) server hosted on the Internet Computer Protocol (ICP) blockchain. This decentralized approach makes the malicious network traffic blend seamlessly with regular web requests, significantly complicating detection by traditional network monitoring tools. Secondary payloads are downloaded and executed from this C2 infrastructure, with execution state being meticulously tracked by the malware.

The most alarming aspect of CanisterWorm is its autonomous propagation mechanism. The malware actively scans for npm authentication tokens, commonly found in `.npmrc` files or as environment variables such as `NPM_TOKEN` or `NPM_TOKENS`. Upon successfully stealing these credentials, a `deploy.js` script within the malware queries the npm registry to identify all packages maintained by the compromised developer. It then systematically increments the patch version number of each of these packages and publishes the malicious updates automatically, thus expanding the attack surface exponentially.

Known Compromised Packages Identified

JFrog researchers have identified a comprehensive list of compromised npm packages and their affected versions. Developers using any of these packages should assume their environments may be compromised and take immediate action. The list includes a wide array of packages across various namespaces, with specific attention drawn to those under the `@emilgroup` and `@teale.io` namespaces, among others.

Developers who have used any of the identified compromised package versions must treat their development environments as compromised. Immediate rotation of all npm publishing tokens, including those stored in `.npmrc` files, environment variables, and CI/CD pipeline secrets, is crucial. On Linux systems, it is recommended to stop and disable the `pgmon` service using `systemctl`, and remove its associated service files and directories. Additionally, the temporary files `/tmp/pglog` and `/tmp/.pg_state` should be deleted.

Affected `node_modules` directories should be purged and rebuilt from scratch using verified and safe package versions. For developers whose tokens have been compromised, manually unpublishing the malicious package versions from the npm registry is necessary, as simply publishing a newer version does not revoke access for users who may have already installed the infected release. A proactive defensive measure is to globally configure npm to ignore scripts by running `npm config set ignore-scripts true`, which will prevent `postinstall` hooks from executing silently on future installations.