New compromised versions detected in CanisterWorm attack

JFrog Security researchers have identified new, previously unreported compromised package versions related to the CanisterWorm npm supply chain attack.

1. Brief overview of attack

The CanisterWorm campaign is a sophisticated, worm-enabled npm supply chain attack initially brought to light by security researchers via previous reports (such as Socket’s and Endor Lab’s). The threat actors behind the attack (tracked as "TeamPCP") have successfully compromised legitimate npm publisher namespaces, such as @emilgroup and @teale.io, by pushing new versions, that include malicious payloads, into SDK packages.

At the core of CanisterWorm is an elaborate execution and persistence mechanism:

• Execution via hooks: The malware is triggered during installation via a malicious postinstall script inside package.json, which drops a Python backdoor onto the infected host.
• Persistence: On Linux environments, it utilizes systemd --user to create a persistent background service named pgmon.
• C2 via ICP: The backdoor continuously polls an Internet Computer Protocol (ICP) canister acting as a dead-drop command and control channel (specifically https://tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io/). It retrieves secondary payloads, saving them to /tmp/pglog and tracking the execution state in /tmp/.pg_state.
• Credential Harvesting Scope: The malware explicitly scans for _authToken values within local project .npmrc files, the user's home directory (~/.npmrc), and system-wide configurations (/etc/npmrc). It also targets the NPM_TOKEN and NPM_TOKENS environment variables, and executes npm config get //registry.npmjs.org/:_authToken.
• Propagation: The worm is capable of autonomously spreading using a deploy.js script. It uses the extracted npm tokens to query the npm registry at npmjs.com (/-/v1/search) for all packages maintained by the compromised user. It then automatically increments the package's patch version and pushes the malicious update using npm publish --access public --tag latest.

2. New compromised versions

Through our continuous monitoring and threat intelligence pipeline, we have identified the complete scope of packages compromised by the CanisterWorm attack.

Crucially, we have detected extra package versions not previously reported in other public disclosures. If you are using any of these specific packages, you must assume your environment is compromised:

Uniquely Identified by Our Research Team:

• @emilgroup/discount-sdk (1.5.1)
• @emilgroup/document-uploader (0.0.10)
• @emilgroup/docxtemplater-util (1.1.2)
• @emilgroup/numbergenerator-sdk-node (1.3.1)
• @emilgroup/partner-portal-sdk (1.1.1)
• @emilgroup/setting-sdk (0.2.1)
• @emilgroup/task-sdk (1.0.2)
• @emilgroup/task-sdk-node (1.0.2)

3. Remediation guidance

If you suspect an infection or identify any of the compromised package versions in your environment, perform the following remediation steps immediately.

Step 1: Containment

CanisterWorm's primary threat is its capability to self-propagate using stolen tokens. You must cut off its access immediately:

• Rotate ALL npm publishing tokens and any CI/CD environment secrets available on the compromised host. This includes tokens found in ~/.npmrc, project-level .npmrc, /etc/npmrc, and the NPM_TOKEN or NPM_TOKENS environment variables.
• Ensure that the scope of your new credentials is fully restricted using granular access policies (e.g., read-only vs. publish) and set expiration dates, rather than relying on traditional permanent tokens.
• Audit your npm logs and package histories to verify no unauthorized publishes have occurred from your own namespace.

Step 2: Eradication of Persistence

On Linux systems, the worm persists by installing a background service via systemd. You need to stop and disable it to prevent further remote payload execution:

systemctl --user stop pgmon.service && systemctl --user disable pgmon.service

Step 3: Cleanup of Malicious Payloads

The threat actor's Python script downloads a secondary payload to a temporary location. You must remove the staging artifacts:

rm -f ~/.config/systemd/user/pgmon.service
rm -rf ~/.local/share/pgmon/
rm -f /tmp/pglog
rm -f /tmp/.pg_state

Step 4: Package Removal

You must purge the infected package dependencies from your project entirely:

• Delete your node_modules folder and clear the cache:

rm -rf node_modules
npm cache clean --force

• Downgrade to known safe versions: Update your package.json to lock the affected SDK packages to the prior, non-compromised versions (e.g., locking @emilgroup packages to versions released before the attack window).
• Reinstall dependencies:

npm install

Step 5: Registry Cleanup

If your own publisher tokens were compromised and the worm successfully published malicious versions under your namespace:

• You must manually unpublish the compromised patch versions from the npm registry. Deleting local files or simply publishing a new version is not sufficient to protect downstream users who might install the compromised version.

Step 6: Long-Term Prevention

To protect your environment from similar supply chain attacks moving forward:

• Global Script Disabling: Consider running npm config set ignore-scripts true to prevent the silent execution of postinstall hooks globally.
• Selective Script Execution: Use tools like @lavamoat/allow-scripts to review and explicitly permit only necessary lifecycle scripts.
• System policies: Implement policies (such as SELinux/AppArmor) to prevent unauthorized writes to ~/.config/systemd/user/.
• JFrog Curation: Implement automated dependency scanning and approval workflows with JFrog Curation to ensure only vetted packages enter your supply chain.

Complete List of Known Compromised Packages: