CanisterSprawl: A Self-Propagating npm Worm Hijacks pgserve, automagik, and Namastex Packages

TL;DR

If anyone in your organization installed any version of pgserve, @automagik/genie, or the @fairwords packages between April 21 and April 23, treat that machine as compromised. The worm runs at install time, harvests secrets, and uses the victim's own npm tokens to publish poisoned versions of every package they own. Rotating credentials is not optional.

Why This Attack Is Different

We have written about npm supply chain attacks repeatedly this year. The axios compromise, the nx attack, and the LiteLLM PyPI incident all followed a similar shape: an attacker hijacks a maintainer account, publishes one or two malicious versions, and ships a payload that exfiltrates secrets.

CanisterSprawl is different in three ways that matter.

1. It is a worm. It does not just steal credentials. It uses the stolen npm tokens to enumerate every package the victim can publish, bumps the patch version, injects itself, and publishes the poisoned versions. The blast radius grows with every infection.
2. It crosses ecosystems. When the worm finds a PyPI token in addition to npm tokens, it jumps to PyPI and replicates the same logic there.
3. It is hosted on infrastructure designed to resist takedowns. The command and control endpoint is an Internet Computer Protocol (ICP) canister, a decentralized smart contract platform. There is no domain to seize and no provider to send an abuse report to.

The combination of these three properties means the attack does not have a clean end state. As long as developers keep installing infected packages and the worm keeps finding new tokens, the campaign keeps expanding.

Timeline of the Campaign

April 21, 2026 — pgserve compromised

Malicious versions of pgserve 1.1.11 through 1.1.14 were published to npm. pgserve is an embedded PostgreSQL server for Node.js, designed for zero-config local development. It is the kind of dependency a developer drops into a side project and forgets about.

The compromised versions added a postinstall hook that downloaded and executed an obfuscated credential-harvesting script. StepSecurity flagged the activity within hours and named the cluster of behaviors CanisterSprawl because of the use of an ICP canister as the exfiltration endpoint.

April 21–22, 2026 — automagik and fairwords packages join the cluster

Within hours, @automagik/genie versions 4.260421.33 through 4.260421.40 were published with the same payload. The version numbers themselves are a tell: the format 4.{YYMMDD}.{N} indicates the worm bumped the version using the current date.

Two @fairwords packages, websocket (1.0.38–1.0.39) and loopback-connector-es (1.4.3–1.4.4), and two @openwebconcept packages, design-tokens and theme-owc (1.0.1–1.0.3), were also compromised in the same window. The pattern is consistent: each victim's npm token is used to publish poisoned versions of every package they can access.

April 22, 2026 — Checkmarx KICS Docker images flagged

The checkmarx/kics Docker Hub repository was flagged for suspicious activity on the same day, surfacing through GitGuardian and Socket reporting. Socket linked the activity to a related actor tracked as TeamPCP, which had previously orchestrated a similar campaign called CanisterWorm. The Checkmarx KICS VS Code extension was also affected.

April 23, 2026 — Namastex.ai packages compromised

Socket and StepSecurity confirmed that several Namastex.ai npm packages were compromised by the same toolkit: install-time execution, credential theft, ICP canister exfiltration, and self-propagation. At this point, security researchers were treating CanisterSprawl, CanisterWorm, and the TeamPCP campaign as the same operational cluster.

How CanisterSprawl Works

Step 1: Install-time execution

The malware ships as a postinstall script in package.json. With npm and Yarn 1 (Classic), the script is run automatically whenever someone runs npm install, npm ci, yarn install, or installs the package as a transitive dependency, including in CI/CD pipelines. There is no need for the developer to import or use the malicious code.

pnpm 10 (released January 2025) and Yarn Berry block lifecycle scripts by default. Teams using those package managers with default settings have a built-in mitigation, though it can still be undone by per-package allowlists.

This is why the worm spreads through CI/CD systems so effectively for npm and Yarn 1 users. Every build agent that resolves the dependency graph runs the script.

Step 2: Credential harvesting

The script enumerates the victim's environment and looks for:

• Environment variables matching token, credential, and provider name patterns (NPM_TOKEN, GITHUB_TOKEN, AWS_*, GCP_*, AZURE_*, OPENAI_*, ANTHROPIC_*, STRIPE_*, and many more)
• Local files: .npmrc, .git-credentials, .netrc, .env and .env.*, AWS and GCP credential files, SSH private keys, kubeconfig files
• Browser artifacts: Chrome Login Data SQLite database, cookies
• Cryptocurrency wallet extensions: MetaMask, Phantom, and similar

This is the same harvesting logic we have seen in previous AI agent infostealer attacks, but with a wider net for developer-specific secrets.

Step 3: Exfiltration to an ICP canister

The collected data is encrypted and POSTed to an Internet Computer Protocol canister. ICP canisters are essentially decentralized smart contracts with HTTP endpoints. Because they run on a public blockchain, there is no traditional domain registrar, hosting provider, or CDN to send an abuse report to. Takedowns require coordinating with the ICP network operator, which is dramatically slower than seizing a domain.

Step 4: Self-propagation

Once the worm has the victim's npm token, it queries the npm registry for every package the token can publish to. For each package, it:

1. Downloads the latest version
2. Bumps the patch version
3. Injects the same postinstall hook
4. Publishes the new version

If a PyPI token is also present, it repeats the process on PyPI. The result is exponential growth: every developer infected becomes a publisher of new infected packages.

Who Is at Risk

You are at risk if any of the following are true:

• A developer or CI agent ran npm install on a project that depends on pgserve, @automagik/genie, @fairwords/websocket, @fairwords/loopback-connector-es, @openwebconcept/design-tokens, @openwebconcept/theme-owc, or any Namastex.ai package between April 21 and April 23, 2026.
• A transitive dependency in your lockfile resolves to one of the affected versions. The worm can hide several layers down the dependency tree.
• Your CI runs on long-lived build agents that cache node_modules and credentials together.
• Your developers store npm or PyPI tokens in .npmrc or ~/.pypirc files on machines that also run npm install on untrusted projects.

If your team works with Supabase or any Node.js backend, the local development environment is the most exposed surface here. pgserve in particular targets developers who want a disposable Postgres for local testing.

What to Do Right Now

1. Search your lockfiles

Run a search across every repository for the affected packages and versions. Do not rely only on the top-level package.json. Check package-lock.json, yarn.lock, and pnpm-lock.yaml.

1# In every repo that uses npm
2grep -rE "pgserve|@automagik/genie|@fairwords/websocket|@fairwords/loopback-connector-es|@openwebconcept/design-tokens|@openwebconcept/theme-owc" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

If any match resolves to a compromised version range, treat the host that produced the lockfile as compromised.

2. Rotate every secret on affected hosts

Assume the worm exfiltrated everything it could see. At minimum:

• npm publish tokens (revoke and reissue)
• PyPI API tokens
• GitHub personal access tokens and SSH keys
• Cloud provider keys (AWS, GCP, Azure)
• Database passwords stored in .env files
• LLM API keys (OpenAI, Anthropic, etc.)
• Any session cookies or refresh tokens cached in browsers on the affected host

Our guide on secrets management walks through how to move these out of .env files in the first place so the next worm has less to take.

3. Audit npm for unauthorized publishes

If a developer's npm token was stolen, the worm may have published poisoned versions of packages your organization owns. Check the publish history of every package your team maintains for new versions published between April 21 and today.

1npm view <your-package> time --json
2npm view <your-package> versions --json

If you find a publish you did not authorize, deprecate and unpublish it immediately, then rotate the publishing credentials and force a clean rebuild from a known-good commit.

4. Disable postinstall in CI by default

CI runners are the highest-leverage target for these worms because they have access to publish tokens and cloud credentials. Disable postinstall execution in CI as a default, and re-enable it only for vetted dependencies.

1# npm
2npm ci --ignore-scripts
3
4# pnpm (default in pnpm 10+, but explicit is safer)
5pnpm install --ignore-scripts
6
7# yarn 1 (Classic)
8yarn install --ignore-scripts
9
10# yarn 2/3/4 (Berry): set in .yarnrc.yml
11# enableScripts: false

Combine this with strict allowlisting of which packages are allowed to run install scripts.

Defending Against Self-Propagating Worms

The general defenses we recommend in our supply chain attack prevention guide all apply here. Three controls deserve special attention because of how this worm works.

Use npm Trusted Publishing

Trusted Publishing replaces long-lived npm tokens with short-lived OIDC tokens issued by GitHub Actions or GitLab CI. There is no static token for the worm to steal. The axios attack was a clear lesson in this — the axios v1.x publish workflow had OIDC configured, but a long-lived NPM_TOKEN left active alongside it gave the attacker a working publish path that bypassed the Trusted Publishing setup.

If your packages still publish with a static NPM_TOKEN, migrating to Trusted Publishing this quarter is the single highest-leverage change you can make. Verify that no long-lived tokens remain valid alongside the OIDC configuration.

Pin and verify dependencies

A self-propagating worm relies on developers and CI runners pulling a poisoned version. If your lockfile is pinned to a specific resolved version with an integrity hash, and your install command refuses to update it (npm ci rather than npm install), the worm cannot reach you through a patch bump.

For Docker images and binaries, verify signatures or attestations before use. Both npm provenance attestations and Sigstore-backed attestations are available for many popular packages.

Isolate token-bearing environments

The npm publish token, the PyPI token, and the cloud credentials should never sit on the same machine that runs npm install on untrusted code. In practice this means:

• Developers run unfamiliar projects inside a container, a VM, or a sandboxed dev environment with no host secrets mounted in
• CI publishes from a dedicated, ephemeral runner that is destroyed after every job
• Long-lived build agents are replaced with single-use runners

This containment is the same principle that should have stopped the second Trivy breach — the first compromise gave the attacker tokens that should not have had access to the CI environment for the second one.

What This Means for Your SOC 2 and ISO 27001 Posture

If you are pursuing or maintaining SOC 2 or ISO 27001, CanisterSprawl maps to several specific control areas your auditor will ask about.

• Vendor and supply chain risk (CC9.2 in SOC 2, A.5.21 in ISO 27001:2022). Auditors increasingly expect a documented process for evaluating open-source dependencies, not just SaaS vendors. A list of approved packages, a way to detect new transitive dependencies, and a way to react when a dependency is compromised are all in scope.
• Access management (CC6.1, A.5.15). Token rotation, short-lived credentials, and least privilege apply to publish tokens and CI tokens, not only to human user access.
• Change management (CC8.1, A.8.32). A poisoned dependency entering your build is an unauthorized change. Auditors will ask how you would detect it and how you would respond.
• Incident response (CC7.4, A.5.26). A documented playbook for supply chain compromises, including the rotation steps above, should exist before you need it. Pair this with the planning side (CC7.3, A.5.24).

If you are working through these controls, our post on vendor management software for SOC 2 and ISO 27001 covers what tools belong in scope. The CanisterSprawl campaign is a good real-world test case to walk through with your auditor.

The Bigger Picture

Self-propagating supply chain worms are not new in concept. The Shai-Hulud campaigns of late 2025 and early 2026, and now CanisterSprawl, mark the operational maturity of the technique. Three things are getting worse, not better:

1. Detection windows are short. pgserve was flagged within hours, but the worm only needs minutes to harvest tokens and propagate.
2. Takedowns are slower. Decentralized C2 infrastructure means the exfiltration endpoint cannot be sinkholed easily.
3. The blast radius compounds. Every infected developer becomes a publisher of new infected packages. The campaign does not have a single point of failure for defenders to attack.

The defensive posture that worked against single-package compromises is not enough. Pinning versions, removing static publish tokens, isolating CI runners, and disabling install scripts by default are not optional anymore.

Conclusion

CanisterSprawl is a reminder that npm and PyPI are not just package registries. They are control planes that an attacker can hijack to push code into thousands of build pipelines at once. The defensive controls that matter most — short-lived publish tokens, pinned lockfiles, sandboxed install steps, and rapid token rotation — are also the ones that earn credit on a SOC 2 or ISO 27001 audit.

If you want help implementing these controls, mapping them to your audit, or running tabletop exercises against supply chain scenarios, get in touch with our team. We have walked dozens of SaaS companies through exactly these scenarios.

Sources

• Self-Propagating Supply Chain Worm Hijacks npm Packages to Steal Developer Tokens — The Hacker News, April 22, 2026
• CanisterSprawl: pgserve Compromised on npm — StepSecurity threat brief
• No Off Season: Three Supply Chain Campaigns Hit npm, PyPI, and Docker Hub in 48 Hours — GitGuardian
• Malicious pgserve, automagik developer tools found in npm registry — InfoWorld
• Namastex.ai npm Packages Hit with TeamPCP-Style CanisterWorm — Socket
• Another npm supply chain worm hits dev environments — The Register