CanisterWorm in the Wild: ICP Canisters and the npm Fallout
Just saw the update regarding the fallout from the Trivy scanner compromise. It seems the threat actors weren't content with just the initial breach and have moved laterally to infect roughly 47 npm packages with a self-propagating worm dubbed "CanisterWorm."
What stands out here is the C2 mechanism. They're abusing ICP (Internet Computer) canisters—essentially tamperproof smart contracts—to handle command and control. This is a nightmare to detect because it looks like legitimate blockchain traffic and interaction.
If you're running Trivy or pulling from npm, you need to audit your dependencies immediately. The worm is self-propagating, so a single compromised package can infect your build pipeline. Check for any suspicious postinstall scripts in your package. files.
Here is a quick script to audit your package-lock. against the list of compromised packages (update the COMPROMISED list with the latest IOCs):
import
import sys
# List of known affected packages (update from the advisory)
COMPROMISED = ["evil-pkg", "canister-dep"]
def audit_lockfile(filepath):
try:
with open(filepath, 'r') as f:
data = .load(f)
except FileNotFoundError:
print(f"Error: {filepath} not found.")
return
if 'packages' not in data:
print("Invalid package-lock. structure.")
return
alerts = []
for path, details in data['packages'].items():
if path == "": continue
pkg_name = path.split('node_modules/')[-1]
if any(c in pkg_name for c in COMPROMISED):
alerts.append(f"Found malicious dependency: {pkg_name} (Version: {details.get('version', 'unknown')})")
if alerts:
print("\nSECURITY ALERT:\n" + "\n".join(alerts))
else:
print("No known compromised packages found.")
if __name__ == "__main__":
audit_lockfile('package-lock.')
Has anyone seen evidence of this spreading to private registries, or is it strictly confined to the public npm repo for now?
We caught this hitting one of our staging environments yesterday. The self-propagation mechanism is nasty; it injects a preinstall script that reaches out to the ICP canister for the next payload.
We've temporarily blocked outbound traffic to .icp domains at the firewall until we have better signatures. If you're using Sigstore or a similar signing policy, now is the time to enforce 'policy always'. Relying on version pinning isn't enough if the maintainer's account is fully compromised.
The ICP canister angle is fascinating but terrifying. Since the canisters are tamperproof smart contracts, taking down the C2 infrastructure isn't as simple as seizing a VPS. The attackers likely hardcoded the logic into the blockchain.
We're pivoting our CI/CD pipelines to use ephemeral builders with strict network egress rules. If the build runner can't talk to the public internet (except for specific allowlists like registry.npmjs.org), the worm can't phone home.
Validating Priya's point, since we can't modify the canister, we must focus on network-level blocking. On the detection side, we implemented a quick CI check for preinstall scripts since legitimate packages rarely use them. You can audit your current environment with this:
find . -name 'package.' -exec grep -l '"preinstall"' {} \;
Investigate any hits immediately; they often contain obfuscated curl commands targeting those canisters.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access