The Rise of Supply Chain Attacks: Why 2025–2026 Changed Everything

For years, “supply chain attack” was shorthand for SolarWinds — a watershed event we kept invoking because nothing quite matched its scale. That era is over. In the last eight months, attackers have shifted from one-off compromises to industrialized, self-propagating, and increasingly automated campaigns that target the open-source registries every modern application depends on. The pattern is clear: the supply chain is no longer a side door. It’s the front door.

This post walks through what changed, why it matters, and what defenders should actually do differently.

What’s actually new

A useful way to frame the shift is by looking at three properties that recent campaigns now share, which previous-generation supply chain attacks did not:

1. Self-replication — malware that propagates through the registry itself, without operator involvement.
2. Targeting the toolchain that defends the toolchain — i.e., compromising the security tools embedded in CI/CD.
3. AI-assisted tradecraft — payloads, recon scripts, and even propagation logic that show signs of being generated by LLMs.

Each of these is visible in incidents from the last six months. Together, they represent a meaningful change in the threat model.

The Shai-Hulud worm: the first registry-native worm

The September 2025 Shai-Hulud incident is the inflection point. ReversingLabs researchers detected a self-replicating worm on the npm registry on September 15, named after the sandworms from Frank Herbert’s Dune. The mechanics were novel and worth understanding in detail.

The infection chain looked roughly like this:

• A maintainer’s npm account is compromised, typically through phishing.
• The attacker publishes a new version of one of the maintainer’s packages with a postinstall script (node bundle.js) added to package.json.
• When a downstream developer or CI pipeline runs npm install, the script executes locally.
• The script scans the host for credentials — npm tokens, GitHub PATs, AWS/GCP/Azure keys, SSH keys — using tools like TruffleHog for credential discovery.
• Stolen credentials are exfiltrated by being committed to a new public GitHub repository named Shai-Hulud under the victim’s own account, exposing them to the world.
• If a valid npm token is found, the worm enumerates other packages owned by that maintainer, injects itself into each, and republishes them.

That last step is the part that breaks the mold. Once the first developer was compromised, there was no stopping the spread. By the time the campaign slowed around September 18, roughly 600 package versions across nearly 200 unique package names had been impacted, including packages briefly published under CrowdStrike’s npm scope.

Two months later it came back, harder. On November 24, 2025, a second worm with similar techniques — Shai-Hulud 2.0 — backdoored 796 unique npm packages totaling more than 20 million weekly downloads. The 2.0 variant moved execution from postinstall to preinstall, which dramatically expanded the blast radius (preinstall runs even when installation later fails), and added a particularly nasty fallback: if the worm cannot replicate or exfiltrate, it attempts to destroy the user’s home directory.

Critically, Shai-Hulud 2.0 doesn’t need a C2 server to spread — it reads its own bundled source to propagate. There is no central infrastructure to take down.

Why this matters technically

postinstall and preinstall lifecycle scripts are a well-known footgun in npm — they run with the developer’s privileges, in the developer’s environment, the moment a package lands. Every defender knows this. The Shai-Hulud campaigns demonstrate that knowing isn’t enough: as long as install scripts execute by default and maintainer accounts can be phished, the registry remains a propagation medium for any worm clever enough to exploit it.

TeamPCP: when the security tools become the payload

In late February through March 2026, a group tracked as TeamPCP ran a sequence of compromises that should be uncomfortable reading for any security team. Between late February and March 2026, the group systematically compromised widely trusted open-source security tools, including the vulnerability scanners Trivy and KICS and the AI gateway LiteLLM, plus the official Python SDK for Telnyx.

Look at that list again. The vulnerability scanners. The exact tools many organizations bolt onto their CI pipelines to detect malicious dependencies are themselves the malicious dependencies.

The TeamPCP attack chain on KICS is illustrative: after compromising Aqua Security’s Trivy first, on March 21, 2026, the attackers used stolen GitHub Personal Access Tokens to force-push malicious commits to all 35 version tags of the checkmarx/kics-github-action repository. Force-pushing tags is a particularly hostile move — it rewrites what consumers thought was an immutable historical reference.

For LiteLLM, the campaign hit a high-value target: a popular AI infrastructure library hosted on PyPI with roughly 3.4 million downloads per day. Two malicious versions sat on PyPI for about three hours before being quarantined — but in a CI ecosystem where pipelines run continuously, three hours is plenty.

The payload was tuned for the environment. The malicious LiteLLM packages were designed to harvest AWS, GCP, and Azure tokens, SSH keys, and Kubernetes credentials, enabling lateral movement and persistence across CI/CD systems and production environments.

A particularly grim wrinkle: the campaign integrated a destructive wiper component, observed on March 23, 2026, that deploys privileged DaemonSets to brick Kubernetes clusters or executes recursive file deletions on non-containerized hosts. Smash-and-grab supply chain operations now include the smash.

Axios and the case for treating maintainers as critical infrastructure

The Axios compromise on March 30, 2026 was the loudest incident of the quarter, and the most instructive about social-engineering risk. Axios is one of the most widely deployed HTTP clients in the JavaScript ecosystem — an open-source library with about 100 million weekly downloads, running in roughly 80 percent of cloud and code environments.

The intrusion did not exploit a vulnerability. Threat actors bypassed Axios’s GitHub Actions CI/CD pipeline by compromising the lead maintainer’s npm account and changing its associated email. The malicious version added a dependency called plain-crypto-js whose postinstall script executed setup.js via Node — same lifecycle-script trick as Shai-Hulud, different operator.

The compromise has been attributed to a North Korean threat actor — broadly, the cluster of activity often associated with Lazarus, which has been targeting software developers and cryptocurrency organizations to generate revenue for the DPRK regime, and in recent years has weaponized open-source ecosystems by publishing malicious npm packages mimicking popular libraries.

Downstream fallout matters here. OpenAI was sufficiently exposed via the Axios dependency chain that it revoked its macOS signing certificate on March 31, 2026 as a precaution. When a single library compromise forces a major AI vendor to rotate code-signing infrastructure, the asymmetry of the supply chain is on full display.

The takeaway from a Mandiant practitioner is worth pinning to the wall. The blast radius of these campaigns will be measured over months as stolen credentials are weaponized; the compromise date and the impact date are not the same date.

The connective tissue: phishing, identity, and AI

Strip away the worm logic and the wipers, and a depressingly simple story emerges. Almost every recent campaign follows the same opening move:

1. Identify a maintainer of a widely-used package.
2. Phish their npm or GitHub credentials, often using a fake “MFA update” page that mimics the registry’s domain.
3. Use the stolen credentials to publish a malicious version that ships in 24 hours to thousands of downstream pipelines.

This is not new. What’s new is the scale and automation layered on top. Once an attacker has one set of maintainer credentials, the worm logic does the rest. There’s no need to keep phishing. The trust graph of the open-source registry does the work for them.

Two trends are accelerating this:

• AI-generated payloads. Unit 42 assesses with moderate confidence that an LLM was used to generate the malicious bash script behind Shai-Hulud, based on the inclusion of comments and emojis — small tells, but consistent with how generated code looks. Earlier campaigns this year went further and weaponized AI command-line tools for reconnaissance directly.
• Identity is now the perimeter. OAuth tokens, API keys, and service accounts have become the primary trust anchors of modern software, and supply chain compromise has industrialized into a scalable, repeatable model used by ransomware crews, access brokers, and state-aligned actors alike.

What defenders should actually do

Most of the practical advice circulating in the wake of these incidents is correct but incomplete. A short, opinionated list:

1. Pin and delay. Treat the first 24–72 hours after any package version is published as quarantine time. Don’t auto-bump. A simple rule that blocks any npm version less than 24 hours old would have prevented downloads of both Trivy and Axios’s malicious releases. Tools like Datadog’s open-source supply-chain firewall and Socket can enforce this at install time.

2. Disable install scripts by default. Use npm config set ignore-scripts true in CI. Whitelist specific packages that legitimately need lifecycle scripts. The cost is real (some packages will need adjustment); the payoff is that a Shai-Hulud-style postinstall payload becomes inert.

3. Phish-resistant MFA on every maintainer account. Hardware-backed WebAuthn, not TOTP, not SMS. Most of the recent npm phishing campaigns succeed because TOTP codes can be relayed in real time on a spoofed login page. Hardware keys break this.

4. Treat CI tokens as crown jewels. GitHub PATs, npm publish tokens, and cloud OIDC roles in CI should be scoped narrowly, short-lived, and audited. The Shai-Hulud worm spread because it found long-lived tokens with publish rights to many packages on a single developer’s machine.

5. SBOMs are necessary but not sufficient. Generate them, store them, and — most importantly — wire them into your incident response. When a truffleHog-style campaign drops, the question “which of our deployed services contain compromised version X.Y.Z of package P?” should be answerable in minutes, not days.

6. Rotate aggressively after any exposure. If your CI ran npm install against a compromised package window, assume the secrets in that environment are gone. Rotate or revoke all potentially exposed PyPI tokens, API keys, SSH keys, and cloud credentials.

7. Monitor for the artifacts of compromise post-hoc. Look for unexpected public GitHub repositories created under your developers’ accounts, branches named shai-hulud, workflow files named shai-hulud-workflow.yml, or repository descriptions containing Sha1-Hulud: The Second Coming. These are the breadcrumbs the worms leave behind.

The structural problem

None of this changes the fundamental asymmetry. A modern application has thousands of transitive dependencies maintained by individuals who are, almost by definition, doing this work for free. Many critical packages are maintained by a single person. Compromise that one person — by phishing, social engineering, or simply offering them money — and you inherit access to a meaningful slice of the world’s software.

Registries themselves will eventually have to change. Mandatory phish-resistant MFA for publishers, mandatory provenance attestations (Sigstore, npm provenance), human-in-the-loop publishing for high-impact packages, and registry-side anomaly detection on package contents are all on the table. Some are already shipping. None are ubiquitous.

In the meantime, the operating assumption for any organization that ships software in 2026 should be this: the next compromised package is already on its way to your CI pipeline. The question is whether you’ll see it land, and how quickly you can respond when it does.

If you’re auditing your own posture after reading this, start with two questions:

• (1) Could you list every package version your production services installed in the last 30 days?
• (2) If a CVE-style advisory dropped tomorrow naming a compromised version of one of your transitive dependencies, how long until you’d know whether you were exposed?

The gap between those two answers is your supply chain risk.