CanisterSprawl: What’s at risk, and what to do next

The campaign tracked as CanisterSprawl is a supply chain intrusion in which malicious npm package versions execute at install time, harvest credentials from developer environments, exfiltrate that material to attacker-controlled infrastructure and then attempt to republish poisoned packages using stolen publisher tokens. In the currently reported cases, the activity affected multiple npm packages, used postinstall execution as the initial trigger and relied in part on an Internet Computer Protocol (ICP) canister for resilient exfiltration. The notable feature is not merely credential theft, but worm-like propagation through software publishing workflows.

What is CanisterSprawl?

CanisterSprawl is best understood as a self-propagating supply chain implant rather than a conventional malicious package. The observed payload executes during package installation, enumerates high-value secrets from the local workstation or CI environment, and attempts to use recovered npm credentials to modify and republish additional packages. Reporting also indicates the presence of PyPI propagation logic, including a Python .pth-based persistence and execution mechanism if the requisite credentials are available. 

Public reporting identified the following affected npm packages and versions:

Why this matters

Most software supply chain incidents stop at one of two objectives: code execution on the downstream host or theft of developer secrets. CanisterSprawl appears designed to go further. Its logic turns a compromised developer workstation or CI runner into a distribution node by harvesting npm publishing credentials and reusing them to seed additional malicious releases. That changes the defensive problem from “did we install one bad package?” to “did one installation give an adversary a path into our software publishing surface?” 

The use of an ICP canister is also tactically relevant. It suggests the operators are choosing infrastructure that is more resistant to straightforward domain or hosting takedowns than a single conventional web endpoint. Socket’s reporting further notes strong tradecraft overlap with earlier canister-backed npm worm activity, including install-time execution, credential theft, off-host exfiltration, and propagation through stolen publisher access. 

Who is at risk?

The immediate at-risk population includes any organization that installed one of the identified malicious versions in a developer workstation, build system, or CI/CD environment. The risk increases materially when those systems contain publisher credentials, cloud secrets, SSH material or package-manager configuration files with active tokens. Public reporting states that the malware targets .npmrc, SSH keys and configs, .git-credentials, .netrc, cloud credentials, Kubernetes and Docker configuration, Terraform and Pulumi material, local .env* files, shell history and related artifacts. 

There is a second-order risk for maintainers and organizations with broad publishing rights. If an exposed environment holds valid npm credentials, the compromise boundary may extend beyond the original host to any package namespace that credential can modify. That is the critical distinction between a malicious dependency and a wormable publisher compromise. 

Technical analysis

The technical pattern described in public reporting is straightforward and effective.

First, the malicious code is triggered through a package postinstall hook. That gives the payload execution during a routine dependency installation event, often in environments that already hold sensitive material and outbound network access.

Second, the implant enumerates local secrets. Socket’s analysis describes collection of registry credentials, SSH and Git-related files, cloud credentials, infrastructure configuration, .env files, shell history, and some browser- and wallet-associated artifacts. The Hacker News separately reports attempts to access Chromium-based browser credentials and cryptocurrency wallet extension data. This indicates the operator is not narrowly focused on npm alone; the payload is designed to maximize post-compromise utility from the developer environment.Third, the data is exfiltrated off-host. Public reporting identifies both a conventional HTTPS webhook at telemetry.api-monitor[.]com and an ICP canister endpoint associated with cjn37-uyaaa-aaaac-qgnva-cai.raw.icp0[.]io. Socket’s writeup additionally describes encryption behavior using a bundled RSA public key with AES-256-CBC and RSA-OAEP-SHA256 when that key material is present.

Fourth, the malware attempts propagation. The published analysis says the payload extracts npm tokens from the victim environment, identifies packages the victim can publish, downloads package tarballs, injects a fresh malicious postinstall hook, and republishes them. Socket also reports embedded PyPI propagation logic that prepares a .pth-based Python payload and uploads malicious Python packages with Twine if usable credentials are found. From a defensive standpoint, that makes this a cross-ecosystem propagation design, not simply an npm credential stealer. 

Socket also notes anomalies consistent with compromise rather than an intentionally malicious new package line, including package-to-repository mismatches in observed release history and shared indicators across multiple package namespaces. That does not by itself establish initial access, but it is consistent with a publisher-compromise hypothesis.

Am I affected?

The first-order question is whether any identified malicious version was installed in your environment. The more important questions are narrower and operationally harder:

• Did the postinstall script actually execute?
• Did it execute on a workstation or runner that contained live npm or PyPI credentials?
• Did that host also hold cloud, Git, SSH or infrastructure secrets?
• Did the system initiate outbound traffic to the reported exfiltration infrastructure?
• Did any package namespaces associated with those credentials publish unexpected releases afterward? 

In other words, package presence is only the start of the investigation. The material risk depends on runtime execution, credential availability, and publisher privilege in the specific environment where installation occurred. For this class of incident, a dependency inventory alone is insufficient to establish exposure or to bound the blast radius.

Defensive implications

For defenders, the central lesson is that modern supply chain malware is increasingly optimized for the developer control plane. The adversary does not need a persistent foothold in production to achieve durable impact. If they can execute during dependency installation on a privileged development host, steal publishing credentials, and republish trusted packages, they can transform ordinary software release workflows into a propagation mechanism.

That implies three immediate priorities: 

• First, remove and block the reported malicious package versions. 
• Second, rotate any npm, GitHub, cloud, SSH, and related credentials that may have been accessible on hosts where those versions were executed. 
• Third, review publish history and artifact provenance for unexpected releases tied to the same maintainers, tokens, or time window. 

Socket’s published hunt pivots, distinctive strings and exfiltration endpoints are useful starting points for retrospective analysis.

References

1. Lakshmanan, R. (2026, April 22). Self-propagating supply chain worm hijacks npm packages to steal developer tokens. The Hacker News. https://thehackernews.com/2026/04/self-propagating-supply-chain-worm.html
2. Socket Research Team. (2026, April 22). Namastex.ai npm packages hit with TeamPCP-style CanisterWorm malware. Socket. https://socket.dev/blog/namastex-npm-packages-compromised-canisterworm
3. Socket. (2026). CanisterSprawl. https://socket.dev/supply-chain-attacks/canistersprawl‍
4. DFINITY Foundation. (2026). ICP canister dashboard entry for cjn37-uyaaa-aaaac-qgnva-cai. Internet Computer Dashboard. https://dashboard.internetcomputer.org/canister/cjn37-uyaaa-aaaac-qgnva-cai