Software Supply Chain Attacks 2026: Self-Propagating Worms

In 2026, software supply chain attacks began spreading on their own. One hacked developer account infects the next, then the next, with no hacker doing the work. A single break-in can reach hundreds of projects.

Three cases defined the year: Shai-Hulud, a worm that spreads across npm; GlassWorm, malware that hides from code review; and a cross-ecosystem campaign that reached even the security scanners teams rely on. Here is how each one works, who is likely behind them, and the four defenses that actually limit the damage.

How the threat model changed

For years the attacker picked a target, found a weak dependency inside it, and exploited that path. The 2026 wave flips the effort. The attacker breaks into one package, lets that package break into its neighbors, and collects any credentials it finds on the way.

Build pipelines are the real target. They hold publish tokens, registry credentials, and signing keys, and they run untrusted code every time a dependency installs. One stolen npm token turns a single break-in into an upload across every package that token can publish. The damage is no longer the one package you installed, but every package those packages depend on, all the way down, which in a modern project means hundreds you never picked yourself.

Shai-Hulud: a package that compromises its own neighbors

Shai-Hulud is the biggest npm story of 2026, a self-propagating worm.

The loop is simple. A developer or a CI job installs a poisoned package. During install, a lifecycle script (usually postinstall) runs on that machine. The script hunts for credentials: environment variables in the CI runner, the contents of ~/.npmrc, cloud metadata endpoints, any cached token it can reach. When it finds an npm publish token, it does not just steal it. It uses it.

With that token, the worm lists every package the maintainer can publish, slips its payload into each one, bumps the version, and republishes. Every project downstream that accepts a caret or tilde range upgrades into a poisoned release without anyone touching the code. Some of those maintainers have publish tokens of their own, so from each new account the loop starts over. The worm keeps spreading after the attacker has walked away, which is what makes Shai-Hulud self-replicating instead of merely widespread.

Lifecycle scripts are why npm is so exposed: npm install runs code from the package by default, so the attacker gets to run code before anyone reads a line of it. The same install that pulls a fix pulls the worm.

Auditing the package you just added is no longer enough. It may have been clean last week and weaponized overnight, through a maintainer three levels up your tree you have never heard of.

GlassWorm: malware that survives code review

GlassWorm, reported in March 2026, hits VS Code and OpenVSX extensions through a different vector: the gap between what your screen renders and what the interpreter reads.

The payload is written in invisible, zero-width Unicode characters that take up no space on screen. In a code review, the diff looks clean. A reviewer reading the pull request sees ordinary, harmless JavaScript, because the malicious instructions render as nothing in the editor and in the web diff viewer.

That is why GlassWorm beats manual code review. Review is a visual act: we trust that what we see on screen is what runs. Zero-width and bidirectional characters break that trust. The interpreter reads every byte, the human reads only the visible ones. An extension can pass a careful review, ship to OpenVSX, and carry a payload no one could have caught without running the file through a hex dump or a Unicode linter. Since OpenVSX feeds several VS Code forks and AI-assisted editors, the reach goes well past Microsoft’s own marketplace.

The fix is tooling that flags non-printable and bidirectional Unicode in source, and treating editor extensions as the privileged, auto-updating code they are. An extension has your editor’s full access to your files and tokens. It deserves the same scrutiny as a dependency and almost never gets it.

The 2026 cross-ecosystem wave

The 2026 wave crossed registries and container ecosystems simultaneously.

A financially motivated crew tracked as TeamPCP ran a campaign through the first half of 2026 that hit a string of widely used developer tools. In March 2026 the Microsoft Defender Security Research team documented a compromise of Trivy, the container and IaC scanner, after the attackers exploited incomplete remediation of a prior issue, abusing mutable version tags to push malicious commits across Trivy’s release tree. The campaign rolled into April: on April 22 they pushed poisoned images to the Checkmarx kics Docker repository and published a malicious @bitwarden/cli build to npm. Earlier in the run they hit a PyPI SDK. The targets covered Go CLI tooling, Docker Hub images, npm packages, and PyPI, so the attackers were loyal to no single registry.

When the scanner itself ships poisoned, the tool meant to find the threat becomes the one that delivers it. The Bitwarden CLI handles secrets by design, so a tampered build is a fast route to credentials, though that npm package was live for only about ninety minutes before it was pulled. The kics image sat on Docker Hub, a repository with millions of pulls, so the infection crossed from package registries into the container world and into CI pipelines that pull images on every run.

A modern build pulls from many sources at once, and each one is a separate channel with its own publishing controls. An attacker needs only the weakest. The surface keeps widening faster than most teams can even list what they pull at build time.

Who is behind it, with measured attribution

Attribution in supply chain attacks is rarely clean, so read the following as assessments, not verdicts.

The crew most directly tied to 2026’s worm activity is TeamPCP, a financially motivated group that surfaced in late 2025. Researchers link the Mini Shai-Hulud waves and the Trivy, Checkmarx kics, and Bitwarden CLI compromises to the same cluster. In May 2026 the group open-sourced its Shai-Hulud framework on GitHub, a modular toolkit for harvesting credentials and poisoning supply chains. Researchers tracking the group characterize its goal as financial: a repeatable, automated way to cash in on developer trust.

Group-IB’s 2026 reporting sets that activity inside a wider field of supply-chain actors. Lazarus, most likely linked to North Korea, publishes malicious npm packages that mimic popular libraries and lures developers with credential-stealing malware through fake job interviews. DragonForce runs a ransomware-as-a-service operation aimed at managed service providers, then rides their admin access into every client downstream. A group tracked as 888 sells access built on shared vendor ties; in one case it compromised a single contractor that served several companies and pulled their source code at once.

What links these groups is a shared calculation: breaking into one upstream supplier or contractor is cheaper and quieter than attacking each target one by one. State actors, ransomware crews, and access brokers have all converged on this approach.

Four defenses that actually shrink the blast radius

Most supply chain advice is generic. These four controls map straight onto the attacks above, with the reason each one works.

Generate and consume an SBOM

A software bill of materials is the inventory you cannot defend without. The cross-ecosystem wave works partly because teams do not know what they pull. Generate an SBOM (CycloneDX or SPDX) at build time, store it as an artifact, and diff it across builds. When the next advisory names a package, answering “are we exposed” should take minutes, not days, and an SBOM diff is what catches a worm’s overnight republish before it reaches production.

Pin dependencies and enforce lockfile integrity

Pinning is the single highest-payoff move against worm spread. The hole is the ^ and ~ version range. A caret range quietly accepts a new minor or patch, which is exactly how a republished poisoned version reaches you with no code change on your side. Pin exact versions, commit your lockfile, install with npm ci instead of npm install in CI, and verify integrity hashes. Where a known-bad release exists, force a pin all the way down:

{
  "overrides": {
    "compromised-pkg": "1.2.3"
  }
}

A pinned, hash-verified lockfile would have blunted Shai-Hulud’s core trick, the silent upgrade into a poisoned release.

Sign artifacts and verify provenance

Stop assuming a registry handed you what the maintainer actually published. Sign build artifacts and check the signature and provenance before you run them. Sigstore’s cosign plus SLSA provenance attestations let you prove where an artifact was built and by which pipeline, then reject anything that fails the check:

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/your-org/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/your-org/your-image:latest

This is the same idea, applied to artifacts. Instead of trusting the channel, you verify every artifact and every identity in the pipeline, the posture our zero trust architecture guide for 2026 applies to network and identity. Artifact verification is the posture a poisoned-scanner case like the March Trivy compromise calls for.

Move to OIDC trusted publishing

Long-lived tokens are the fuel that lets a worm spread. Shai-Hulud spreads because it finds a reusable npm token in CI and replays it. Most CI setups have exactly one long-lived npm token, added years ago by someone who has since left the company. OIDC trusted publishing gets rid of the token: the registry trusts a short-lived identity, scoped to one workflow and minted fresh each run, so there is nothing lasting to steal from ~/.npmrc or a runner’s environment. No standing credential means no worm fuel. If you publish from CI in 2026, this is the change that closes the loop the worm runs on.

Frequently Asked Questions

What is a software supply chain attack?

It poisons software before it reaches you, by tampering with a dependency, a build tool, a registry, or a maintainer’s credentials. You then pull in the malicious code through your normal install or update, instead of through a direct break-in to your own systems.

What makes Shai-Hulud different from a normal malicious package?

It spreads on its own. A normal malicious package sits in a registry and waits to be installed. Shai-Hulud steals the publish tokens of whoever installs it, uses them to poison and republish that maintainer’s other packages, then repeats from each new account it reaches, all without the attacker lifting a finger.

How does GlassWorm hide from code review?

It writes its payload in invisible, zero-width Unicode characters that show as nothing on screen. A reviewer reading the diff sees clean code, because the malicious instructions take up no space, while the interpreter still reads and runs every byte.

Which tools were hit in the 2026 cross-ecosystem wave?

A TeamPCP campaign hit Trivy in March 2026, documented by Microsoft Defender Security Research, then the Checkmarx kics Docker image and the @bitwarden/cli npm package on April 22, with earlier PyPI activity in the same run. It covered Go CLI tooling, Docker Hub, and several package registries, not one ecosystem.

Who is behind the 2026 supply chain attacks?

Security researchers link the Mini Shai-Hulud waves and the Trivy, kics, and Bitwarden CLI compromises to a financially motivated crew called TeamPCP. Group-IB’s 2026 report places them in a wider field of supply-chain actors, including Lazarus, DragonForce, and a group tracked as 888. Attribution stays an assessment, not a certainty.

What is the single most effective defense?

Against worm spread specifically, pin exact versions with a hash-verified lockfile, and pair that with OIDC trusted publishing to get rid of long-lived tokens. Pinning stops the silent poisoned upgrade; OIDC removes the credential the worm needs to spread.

The takeaway

The 2026 wave rewards teams that know what they run and check it before running it. Start with two moves this quarter: pin and hash-verify your lockfiles to kill silent upgrades, and switch CI publishing to OIDC so there are no long-lived tokens to steal. Add SBOM generation and cosign verification after that. None of it is exotic, and together it turns one hacked maintainer back into a contained incident instead of a self-spreading one.