New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
Three shifts in supply chain attack strategy that should change how you defend: self-propagating worms, decentralized C2, and AI infrastructure targeting.
April 27, 2026
4 Min Reads
Endura Security
Here's a thought experiment. Imagine you're an attacker who just compromised a single npm maintainer's credentials. A year ago, you'd probably exfiltrate what you could from that package's consumers and call it a win. Today? You'd use those stolen credentials to discover every other package the maintainer can publish, inject your payload into all of them, and let the worm propagate to the next set of maintainers, each compromise funding the next. You'd exfiltrate data not to a server you rent (and that law enforcement can seize), but to a smart contract on a decentralized blockchain that nobody can take down. And you'd specifically target AI tooling, because AI infrastructure is where all the best secrets live.
That's not a thought experiment. That's March and April 2026.
Our previous articles dissected the Trivy cascading compromise and the Axios maintainer account takeover. Since then, the pace hasn't slowed - it's accelerated, and the playbook has evolved. Looking across the incidents of the last few weeks, three shifts stand out that defenders need to internalize.
The most consequential change in supply chain attack methodology isn't a new vulnerability class or a clever social engineering trick. It's that attackers have operationalized self-propagation as a standard feature.
In the original CanisterWorm campaign (March 20-23), TeamPCP took credentials stolen during the Trivy breach and used them to infect 141 malicious package artifacts across 66 unique npm packages. The mechanism was elegant in its brutality: a postinstall hook ran a findNpmTokens() function that harvested npm authentication tokens from ~/.npmrc, project-level configs, environment variables, and live npm configuration queries. Those tokens were passed to a detached deploy.js process that queried the npm registry, discovered every package the stolen token could publish to, incremented the patch version, injected the CanisterWorm payload, and republished with --tag latest. Each victim became the vector for the next wave.
Then, on April 21, it happened again. Security researchers identified a new worm strain, dubbed "CanisterSprawl," targeting npm packages tied to Namastex Labs, an agentic AI company. The compromised packages included @automagik/genie (an AI coding agent CLI) and pgserve (an embedded PostgreSQL server for dev environments). The tradecraft was nearly identical: install-time execution, credential harvesting, off-host exfiltration via Internet Computer Protocol (ICP) canisters, and self-propagation logic designed to jump to every namespace the stolen tokens could reach. Analysis of the malicious code revealed strong overlap in technique, code lineage, and infrastructure with TeamPCP's prior campaign, including an explicit code reference to a "TeamPCP/LiteLLM method" inside the malicious payload - though formal attribution remains unconfirmed since the specific ICP canister identifiers differed.
The critical takeaway isn't that worms exist in the npm ecosystem. It's that the tooling is maturing into a repeatable operational pattern. When the same self-propagation logic appears across multiple campaigns with different canister IDs and slightly different targets, you're not looking at a one-off experiment. You're looking at a playbook that's being shared, refined, and redeployed. Defenders can no longer treat a single compromised package as an isolated incident - it's the tip of a propagation chain, and your exposure assessment needs to account for second- and third-order effects.
Every incident response runbook has a step that says something like "work with hosting providers and registrars to take down attacker infrastructure." For the last two decades, that's been a reasonable assumption. Attackers rent servers, buy domains, stand up C2 infrastructure, and defenders can burn it down through legal channels, abuse reports, and law enforcement cooperation.
The CanisterWorm and CanisterSprawl campaigns broke that assumption. Both used Internet Computer Protocol (ICP) blockchain canisters as their exfiltration and C2 endpoints. An ICP canister is a tamper-proof smart contract deployed on a decentralized network. Its canister ID cannot be removed through conventional law enforcement channels: no registrar takedown, no DNS sinkholing, no hosting provider abuse ticket. Removing it requires either the canister's own controller key or a governance vote by the Internet Computer's Network Nervous System. Defenders can compel neither.
The Trivy attack's LiteLLM compromise demonstrated a similar philosophy with its fallback mechanism: if primary C2 infrastructure failed and a GITHUB_PAT was accessible, the malware created a public repository on the victim's own GitHub account and uploaded stolen data as release assets. The attacker turned the victim's legitimate infrastructure into exfiltration infrastructure.
These aren't exotic techniques anymore. The March 2026 CanisterWorm campaign was the first publicly documented instance of ICP infrastructure being abused for malicious C2. CanisterSprawl in April confirmed it has matured from novel experiment to standard operating procedure. If your response plan assumes you can sinkhole the attacker's domain, you need a new plan.
The Vercel breach, disclosed on April 19, tells a different kind of supply chain story, but one that converges on the same theme. A Context.ai employee's machine was infected with Lumma Stealer malware (reportedly after downloading game exploits). The stolen credentials included Google Workspace OAuth tokens. A Vercel employee had connected Context.ai's "AI Office Suite" to their corporate Google Workspace account with broad OAuth permissions. The attackers rode that trust chain - from an infostealer on a third-party vendor's employee laptop, through an OAuth token, into Vercel's internal systems - ultimately accessing environment variables that weren't marked as sensitive. The stolen data appeared on BreachForums with a $2 million asking price.
Look at the targets across these campaigns. LiteLLM sits between applications and every major AI provider - OpenAI, Anthropic, Azure, Google - often holding API keys for all of them simultaneously. Namastex Labs builds agentic AI tooling; their @automagik/genie package is a CLI for deploying autonomous AI agents. Vercel's breach exposed environment variables that could include AI service keys, deployment secrets, and database credentials. Context.ai was literally an AI tool that had full read access to Google Drive.
Attackers have noticed what defenders have been slow to acknowledge: AI infrastructure is a credential aggregator. A single compromised AI proxy, agent framework, or development tool can yield API keys for dozens of downstream services. When the CanisterSprawl worm specifically targeted developer environments running AI tooling, it wasn't random. Those environments are where the highest density of high-value secrets lives: LLM API keys, cloud credentials, registry tokens, and Kubernetes configs all coexisting in the same process space.
Across these incidents, the common thread is credential-chain propagation: each compromise yields credentials that unlock the next target. TeamPCP went from Trivy to Docker Hub to npm to Checkmarx to LiteLLM in five days. The CanisterSprawl worm automated the same pattern at machine speed. The Vercel breach cascaded from an infostealer through an OAuth trust chain across three organizations.
The unique twists matter too. CanisterSprawl's targeting of agentic AI packages represents a deliberate narrowing of scope, trading broad reach for higher-value targets. The Vercel breach demonstrates that OAuth trust relationships are supply chain dependencies, even though they don't show up in any SBOM. And the convergence of state-aligned actors (Microsoft attributed the Axios compromise to Sapphire Sleet, a North Korean threat group) with apparently independent operators (TeamPCP) on similar techniques suggests that supply chain attack methodology is diffusing rapidly across the threat landscape.
Blast radius assessment is now recursive. When a package in your dependency tree is compromised, the question isn't just "what did it do to my environment?" It's "what credentials did it exfiltrate that could be used to compromise other packages I depend on?" Your dependency graph has second-order exposure you're probably not modeling.
Your incident response plan needs a "can't take down C2" branch. Blockchain-based exfiltration infrastructure means stolen data may be irrecoverable and C2 channels may be persistent. Shift your focus from disrupting attacker infrastructure to ensuring there's nothing worth stealing in the first place: credential isolation, ephemeral tokens, and minimal privilege.
OAuth grants are supply chain dependencies. Every third-party app your employees connect to corporate accounts is an implicit trust relationship with that vendor's security posture. The Vercel breach started with an employee granting "Allow All" Google Drive access to a startup AI tool. If you're not inventorying and reviewing OAuth grants with the same rigor you apply to code dependencies, you have a blind spot.
AI tooling environments need the strictest controls, not the loosest. The "move fast" ethos of AI development has created environments where developers routinely grant broad permissions to experimental tools. Attackers know this. These environments need more isolation and tighter credential scoping than your production infrastructure, not less.
Each of these incidents involved runtime behavior that was completely anomalous for the compromised component, and completely invisible to static security controls. SBOMs, signatures, and provenance attestations verified what these packages were. None of them could detect what they did. Endura's eBPF-based runtime sensor operates at the kernel level, observing actual process behavior during CI/CD execution. The policy enforcement model maps directly to the failure modes in these attacks:
Unauthorized network connections. Every worm variant, CanisterWorm, CanisterSprawl, the Axios RAT, established outbound connections to attacker-controlled infrastructure during npm install or pip install. Endura's ip.connect policy specifies exactly which processes can connect to which hosts on which ports. A policy restricting npm to registry.npmjs.org on port 443 would block exfiltration to ICP canisters, typosquatted domains, and any other unauthorized endpoint, regardless of whether that endpoint is on a conventional server or a decentralized blockchain.
Unauthorized filesystem operations. The CanisterWorm's credential harvesting swept 50+ file paths for SSH keys, cloud credentials, .npmrc tokens, and wallet files. The LiteLLM compromise wrote a persistent loader to ~/.config/sysmon.py. The Axios payload wrote platform-specific binaries and then erased its tracks. Endura's path.open, path.write, and path.create policies enforce which processes can read and write which paths. A build step that suddenly starts reading ~/.ssh/id_rsa or writing to ~/.config/ triggers a policy violation.
Unauthorized process execution. Self-propagation requires spawning child processes: deploy.js running as a detached background process, the Axios payload executing downloaded RAT binaries, the LiteLLM .pth mechanism firing on every Python interpreter startup. Endura's path.execute policy uses a three-part format (parent_path|interpreter_path|target_path) that tracks the full execution chain. An unexpected process lineage, npm spawning node spawning an anonymous script that spawns curl, is immediately visible and blockable.
Unauthorized memory operations. The Trivy malware used /proc/<pid>/mem access to dump secrets from GitHub Actions Runner processes, bypassing log masking. Endura's hook.mem policy controls direct process memory access, detecting and blocking the process_vm_readv operations used in these injection attacks.
The key architectural advantage is that these policies operate in enforce mode - they don't just detect anomalous behavior, they block it. When a compromised package tries to phone home to an ICP canister during npm install, the kernel denies the connection. The package can't exfiltrate credentials it can't transmit.
The supply chain attacks of March and April 2026 aren't aberrations. They're the new operational tempo. Attackers have learned that compromising one upstream dependency provides access to thousands of downstream environments, and they've built tooling that automates the propagation. They've moved their infrastructure onto platforms that can't be taken down. And they've identified AI tooling as the richest credential environment in most organizations. Static inventory controls, SBOMs, signatures, provenance, remain necessary. But they are fundamentally insufficient against attacks that operate within the trust boundary of legitimate packages. The only layer that can distinguish a clean npm install from a compromised one is the layer that observes what actually happens at runtime. The question isn't whether your supply chain will face one of these attacks. It's whether you'll see it when it happens.
Learn how Endura Security's eBPF-based platform provides runtime enforcement across your CI/CD pipelines and production workloads. Request a demo to see how kernel-level policy enforcement blocks credential theft, unauthorized network connections, and anomalous process execution, even when the compromised component is a package you trust.
Ready to put this into practice?
