Three Supply Chains, One Trust Relationship: CanisterWorm, ClawHavoc, and the AI Developer-Tool Attack Surface

On April 21, 2026, at 22:14 UTC, a self-propagating supply-chain worm published its first poisoned npm release. By the end of the day, it had shipped three compromised versions of pgserve — an embedded PostgreSQL server used in development — and seven compromised versions of @automagik/genie, a command-line AI agent that opens pull requests. Both packages are maintained by Namastex Labs, an agentic-AI company, and had combined weekly downloads of roughly 8,000 as of that morning. Socket reports the Namastex packages use TeamPCP-style "CanisterWorm" tradecraft and is tracking this specific incident as CanisterSprawl; we use "CanisterWorm" below as shorthand for the tradecraft lineage rather than the incident name.

Seen in isolation, it is a fast npm supply-chain attack of a shape the ecosystem has seen before. Seen in context, it is the third pressure point on the AI developer-tool supply chain this quarter, and the three points are mutually reinforcing in a way that matters for every team that ships or operates agent tooling.

---

What CanisterWorm actually does

The compromised releases are:

• pgserve versions 1.1.11, 1.1.12, and 1.1.13, all published on April 21.
• @automagik/genie versions 4.260421.33 through 4.260421.39, published on the same day.

npm has since taken down the malicious releases, but any machine that ran npm install while they were live still executed the payload.

The attack chain is compact and ugly:

1. Install-time execution. Each poisoned package ships a postinstall hook — the hook npm runs automatically whenever a package is installed. There is no consent prompt and no user interaction; ordinary npm install output may not make the malicious behavior obvious.
2. Credential theft. The postinstall script searches the environment for a wide range of credential names — npm and PyPI tokens, AWS / GCP / Azure keys, GitHub tokens, and a long list of CI / registry / LLM-platform tokens — along with credential files in standard locations. Anything it finds gets packaged for exfiltration.
3. Canister-based exfiltration. The stolen data is sent to an ICP canister — a smart-contract-like program running on the Internet Computer network — which is where the "Canister" name comes from. It is an infrastructure choice that may complicate takedown compared with an ordinary domain-and-hosting setup.
4. Self-propagation logic. If the payload finds a valid npm publish token on the compromised machine, it attempts to publish new poisoned versions of other packages the token can access. Socket describes this as self-propagation logic "intended to compromise additional packages" rather than confirmed onward spread from every victim.
5. Multi-ecosystem design. The payload also contains PyPI propagation logic using a .pth-based payload, which suggests the campaign was designed to extend beyond npm. Public reporting stops short of confirming successful PyPI compromises in this Namastex incident.

Socket has drawn a line from the techniques used here to TeamPCP's earlier CanisterWorm activity, which ran through the Trivy compromise last month — install-time execution, credential theft from developer environments, canister-backed infrastructure, and self-propagation logic. Socket stops short of confidently attributing this specific incident to the same actor; the techniques match, the actor identification does not.

---

Why this is the third layer, not the first

Read CanisterWorm as an npm incident and the story sounds familiar: another postinstall-hook credential stealer, another takedown a few hours later, another rotation day. What makes this quarter different is that npm is not the only supply chain aimed at AI developer tooling right now. It is the third of three, and all three are hot at the same time.

Layer one: the agent runtime

OpenClaw is the agent runtime at issue. Across February and March 2026 it disclosed multiple serious advisories, including GHSA-rqpp-rjj8-7wv8 on March 13 — a CVSS 9.9 scope-escalation flaw affecting certain shared-auth backend-connection configurations, not a generic "any authenticated user" escalation, though still severe enough to warrant out-of-band patching.

The overall volume is what makes the runtime an interesting surface. The community-maintained OpenClawCVEs tracker lists roughly 139 OpenClaw security advisories published between February 2 and April 17, 2026 — about 75 days and a shade under two advisories per workday, with 3 rated critical and 33 rated high. Only 13 of those advisories carry assigned CVE IDs; the rest are vendor-level advisories that still describe real defects. Either way you count, it is a lot of triage per week.

The exposed fleet is not theoretical either. SecurityScorecard's February 2026 scan found more than 135,000 OpenClaw instances reachable from the public internet with insecure defaults. A January 31 Censys post separately identified 21,639 exposed instances, and subsequent sweeps have been reported in the tens of thousands — numbers that move around with tooling and cleanup, but keep the exposed population at a scale that matters.

At roughly two new advisories per workday, advisory volume is high enough that teams without a disciplined triage process will struggle to keep up. Triaging every new OpenClaw advisory inside 48 hours is a meaningful ongoing commitment at this cadence, and teams that do not triage at all will fall weeks behind the disclosure stream by the end of the month.

Layer two: the marketplace

ClawHub is OpenClaw's plugin marketplace, the place agents load "skills" from. Antiy CERT reports that at least 1,184 malicious skills have appeared on ClawHub across the campaign's history — plugin-style packages that extend OpenClaw's capabilities through scripts, configuration, and resources — which Antiy classifies as Trojan/OpenClaw.PolySkill. The marketplace had roughly 3,498 total listings at the time of Antiy's writeup. Earlier in the campaign, Koi Security counted 341 malicious skills among 2,857 listings. The campaign is tracked as ClawHavoc; the first malicious skill appeared on January 27, 2026, and activity surged on January 31.

Antiy attributed the malicious packages to 12 uploader IDs, with one uploader ID accounting for 677 packages on its own.

ClawHavoc did not need to exploit a vulnerability. The attacker uploaded convincing-looking skills and waited for users to install them. This is the same failure mode as typosquatted and "legitimate-looking" packages on any open registry — with one important difference. The agent-skill ecosystem appears to have less visible security tooling and scrutiny than major package registries: no billion-downloads-per-week canary to notice anomalies, and far fewer independent eyes on install-and-run than npm or PyPI. When Koi's February audit finds roughly 12% of skills hostile at a snapshot, install-and-run becomes install-and-hope.

Layer three: the registry

npm is the registry. CanisterSprawl is the April 21 data point in what is now a standing pattern: credentials stolen at install time, used to attempt compromise of more packages, used to compromise more developers. The Axios campaign, the Trivy / TeamPCP compromise, the shai-hulud wave from last year, and now CanisterSprawl — different specifics, same shape. Install-time execution is the primitive the npm ecosystem has not hardened, and each attacker iteration exploits it a little harder.

---

Why the three layers compound

Agent runtime, marketplace, and registry are three independent trust relationships. They are defended by different teams, scanned by different tools, and patched on different schedules. They also converge in exactly the same place: the developer's machine and the CI environment that inherits its credentials.

An attacker picking any single layer can reach the same general blast radius.

• CanisterSprawl reaches the developer laptop through a postinstall hook run by routine npm install.
• ClawHavoc reaches the same laptop through a skill the developer installs under the assumption that marketplace skills are vetted.
• A mass-exploitation wave against the next OpenClaw critical advisory reaches the laptop through whatever internet-exposed instance happens to be running a forgotten dev branch.

Three different doors, often the same room behind them.

The three layers are also mutually accelerating. A critical advisory in OpenClaw drives researchers and attackers alike to look harder at ClawHub for vulnerable or malicious skills. A successful ClawHub campaign signals that AI-developer-tool supply chains have lower tooling density than npm, which rewards shifting attacker effort up the stack. A worm like CanisterSprawl — whose propagation logic scales with how many npm packages a victim maintains — is, on paper, more productive against the dense, interconnected maintainers who build AI-dev infrastructure than against an average npm contributor. A success at any one layer makes the other two more attractive, not less.

---

What to do this week

If your team installs, writes, or operates AI developer tooling, the defenses are ordinary, which is the part that matters. None of this requires a new product or a new framework. It requires that the basics are actually in place.

1. Rotate credentials if you may have installed either package. If npm install resolved @automagik/genie@4.260421.33 through 4.260421.39 or pgserve@1.1.11, 1.1.12, or 1.1.13 on any developer machine or CI runner on or after April 21, 2026, treat that environment as compromised. Rotate every token reachable from it: npm, PyPI, GitHub, AWS / GCP / Azure, registry logins, deploy keys, anything else in environment variables or on disk. A machine that ran the payload has had several days to leak credentials to an actor whose code attempts to use stolen npm tokens to expand.

2. Turn off npm install scripts by default. On developer machines, run:

npm config set ignore-scripts true

This blocks the entire class of postinstall-hook malware — the specific primitive CanisterSprawl uses, and the same primitive Axios, TeamPCP, and shai-hulud used before it. Re-enable install scripts only for packages you have specifically audited. A few packages genuinely need install scripts (native addons, platform-specific binaries); the vast majority do not. For CI, the same flag works, and CI is where the payoff is highest because CI is where your secrets live.

3. Pin agent-runtime and agent-tool dependencies to exact versions. Floating ranges (^1.2.0, ~1.2.0) will silently absorb the next poisoned release. Exact pinning (1.2.0, or better, a commit SHA for GitHub-sourced tooling) will not. Exact pinning on tools that update frequently is not the overhead it sounds like: Dependabot / Renovate with required-review gating gives you the updates without giving up the gate.

4. Put self-hosted OpenClaw behind authentication and egress controls. OpenClaw has had insecure-default and misconfiguration problems severe enough to leave many deployments exposed, and the 135,000-instance SecurityScorecard count is what an attacker would rather not tell you about. At minimum, require authentication on every endpoint, put the admin surface on an internal-only network, segment outbound network egress so a compromised agent cannot reach arbitrary internet destinations, and keep the instance off the public internet entirely unless there is a specific reason otherwise.

5. Treat the skill marketplace like any unvetted third-party code. Pin skill versions, read before you install, and assume hostile until verified. If the skill your agent loads does not need filesystem or network access, configure it so it does not get filesystem or network access. Sandboxing here costs less than cleanup.

---

What this changes

Nothing in the action list is new advice. What is new is that all three layers of the stack are live attack surface at the same time, which means no single mitigation is enough on its own.

A year ago, "supply chain security" for an AI-tooling team mostly meant dependency scanning against npm. That is still necessary and still correct — but it is now one of three scans you need running, not the whole job. The agent runtime you install needs the same CVE hygiene as any other piece of server software. The skill marketplace you load from needs the same vetting as any other third-party code source. And the registry-level postinstall threat is the one people have been complaining about for a decade and has finally become the thing everyone means when they say "supply chain."

The defense is structural, not heroic. Pin what you can. Turn off install scripts by default. Assume the marketplace is hostile. Assume the runtime has a critical in the queue. None of that is dramatic. It is the difference between being part of the next statistic and not.

---

A note on Rafter

Rafter combines multiple scanners — Betterleaks, Trivy, Bandit, Checkov, OpenGrep, and our own AI scanner — and supports pre-commit hooks and CI-triggered scans on pushes and pull requests when configured. For the registry layer specifically, the dependency-analysis scanners can flag known vulnerable npm and PyPI versions once advisory data is available to them, which helps close the window between an advisory publishing and the poisoned package getting merged into your codebase.

Worth saying plainly what that does and doesn't do. It helps close the advisory-to-merge gap, which is where most of the blast radius lives in a typical supply-chain incident. It does not close the window between a postinstall hook firing on a developer's laptop during a routine npm install and the advisory existing at all. That window is what ignore-scripts, pinning, and treating npm install as a privileged operation are for. The scanners are a complement to those habits, not a substitute.

If you are auditing your pipelines after this week and want a faster way to check what your dependency tree looks like today, Rafter's fast scan covers SAST, dependency analysis, and secrets across your repository in a few minutes.

---

The bigger picture

CanisterSprawl is not the worst thing that has happened to the AI-developer-tool supply chain this quarter, and it will not be the last. A self-propagating worm in npm, a marketplace seeded with over a thousand hostile skills across its history, and two advisories per workday against the runtime underneath are three views of the same underlying fact: the tooling an AI-engineering team installs to go faster is, by design, deep inside the trust boundary, and every actor who wants access to that trust boundary now knows where to aim.

Delayed basic hardening is often what leaves teams exposed when the next incident lands. Three days of routine hygiene this week pays for itself the first time the next worm shows up.

---

Further reading

• When the Scanner Becomes the Weapon: The Trivy / TeamPCP Compromise
• Localhost Is Not a Trust Boundary: What ClawJacked Proves About Agent Gateways
• From a Roblox Cheat to a Vercel Breach: The Context.ai Chain
• The Axios npm Attack: How a Social Engineering Campaign Compromised 100 Million Weekly Downloads
• Dependency Scanning and SCA: A Complete Guide