Supply Chain Attack

A supply chain attack, also called a software supply chain attack or supply chain compromise, is an attack on a trusted supplier, such as an open source package, a build pipeline, or an update server, that turns the supplier's own distribution channel into the delivery mechanism. Victims install the malicious code themselves, through a channel they already trust.

The mechanism is delegated trust. A package manager, an auto-updater, or a CI runner fetches whatever a supplier publishes and runs it with the consumer's own privileges, so the attacker never has to break into the victim. One malicious release reaches every consumer whose next install or update resolves to it. In 2025 and 2026, most malicious npm releases ran their payloads during installation, before any application code loaded and before any advisory existed.

The fact that matters most is speed. The xz-utils backdoor sat in release tarballs for 34 days before anyone reported it. The malicious axios release in March 2026 was publicly reported in two and a half hours, and that was still long enough. Our position: a supply chain attack has to be stopped where code is fetched and executed, by analyzing what the artifact actually does. CVE scanning cannot do that, because malware rarely gets a CVE. Signatures and provenance cannot do it alone, because the 2026 worms published through their victims' own legitimate pipelines.

A supply chain attack reaches its victims through something they obtained from a supplier, not through their own systems. MITRE ATT&CK catalogs it as technique T1195, Supply Chain Compromise, and defines it in one sentence: "Adversaries may manipulate products or product delivery mechanisms prior to receipt by a final consumer for the purpose of data or system compromise."

MITRE splits the technique by supplier type: software dependencies and development tools (T1195.001), software products and their update channels (T1195.002), and hardware (T1195.003). This entry covers the first two, because that is where the volume is. A hardware implant needs physical access to a factory or a shipment. A software implant needs one publish credential, and every link of the software supply chain holds one.

Two boundaries are worth drawing. A vulnerable dependency, such as Log4Shell in 2021, is a supply chain risk but not a supply chain attack: nobody planted the bug. A new malicious package published under a lookalike name, such as a typosquat, attacks the consumer's choice of supplier rather than a supplier they already trust. We count both typosquats and hijacked releases as supply chain attacks, because in both cases the registry delivers the payload. Hijacked releases do more damage, because version ranges install them for you.

A supply chain attack works by taking control of one link that consumers have already authorized to send them code, then waiting for their tools to fetch and run it. That authorization is built into ordinary dependency management, for good reasons.

Modern tooling delegates three decisions to suppliers. The first is which code you get: a version range, an auto-updater, or a floating container tag lets the supplier choose the next version. The second is when it runs: npm lifecycle scripts, Python startup hooks, Cargo build scripts, and CI steps execute supplier code during install, startup, or build. The third is with what privileges: the installing user's, which on a CI runner include deploy keys and publish tokens. Each delegation exists to save work. Ranges deliver bug fixes without a manual upgrade, install scripts compile native modules, and CI needs credentials to ship.

A single line of a manifest shows the first delegation:

{
  "dependencies": {
    "axios": "^1.14.0"
  }
}

On March 31, 2026, that range resolved to the malicious axios@1.14.1 on any fresh install. Nothing in the consumer's repository changed. The new version added one dependency, plain-crypto-js@4.2.1, whose postinstall script dropped a remote access trojan.

Every supply chain attack answers three questions in order, and each answer is a place where a defense can act:

• Entry: which trusted link the attacker controls. Usually a maintainer account, a maintainer's identity, a build system, or a hosted script or CI action.
• Reach: how the payload travels from that link to victims. Range resolution, signed auto-updates, mutable tags and floating images, or self-propagation.
• Trigger: when the victim's own tooling executes it. An install hook, interpreter startup, a build or CI step, or the application's runtime.

Figure 1 places the three stages along the path code travels, from supplier to distribution to consumer. Entry happens on the supplier side: a maintainer account (the Qix compromise, axios, ua-parser-js), a maintainer's identity (the event-stream handoff, the xz-utils co-maintainer), a build or CI system (SolarWinds, the TanStack compromise, the LiteLLM compromise), or a hosted script or action (Codecov, the tj-actions/changed-files compromise). Reach happens in distribution: a version range resolving to the new release (^1.14.0 to axios 1.14.1), a signed auto-update (SolarWinds Orion, fewer than 18,000 customers), a mutable tag or floating image (tj-actions v1 through v45.0.7, LiteLLM's latest tag), or self-propagation (the Shai-Hulud worm, Mini Shai-Hulud, and Miasma). The trigger happens on the consumer side: an install hook (preinstall, postinstall, binding.gyp, a git dependency's prepare script), interpreter startup (LiteLLM's .pth and sitecustomize.py files), a build or CI step (the xz tarball's m4 file, Codecov, tj-actions), or runtime in production (SUNBURST, the Qix wallet hooks in browsers). Supplier controls act on entry, registry and resolver controls act on reach, and consumer controls act on the trigger.

The twelve incidents below cover each entry point, reach mechanism, and trigger in Figure 1. Dates are the first malicious release.

Sources: npm on event-stream, CISA ED 21-01, SolarWinds' SEC filing, Codecov, CERT-EU on ua-parser-js, and Socket's reports linked below.

Three patterns run down the columns.

The entry column is mostly people and credentials, not code bugs. The event-stream and xz-utils attackers earned maintainer trust. The Qix compromise started with a 2FA-reset email from support@npmjs.help. The axios, ua-parser-js, and Shai-Hulud cases were maintainer account takeovers. The exceptions are CI misconfigurations, such as Codecov's Docker image and TanStack's pull_request_target workflow, and those exposed credentials too.

The trigger column moved to install time. Five of the six npm incidents in the table since 2021 executed during npm install, through install scripts or the implicit node-gyp build. Install time is where most supply chain attacks execute, and default-on dependency lifecycle scripts were a design mistake. pnpm 10 corrected it on January 7, 2025, and npm 12 on July 8, 2026, according to the npm registry's publish times for both releases. Neither fix reaches the other triggers: the Qix payload ran in browsers, LiteLLM ran at Python startup, and tj-actions ran inside CI.

The reach column needs no mistake from the victim. Every row used a mechanism working as designed: a caret range, a signed update, a tag, a transitive dependency nobody chose directly. That is the defining property of a supply chain attack, and the reason "be careful what you install" is not a defense.

Supply chain attacks that once stayed hidden for months are now reported within hours, as long as they are loud. Figure 2 measures each incident from the first malicious release to the first report we can date from a primary source.

For the npm and PyPI rows, the endpoint is Socket's published report, so each window is an upper bound. Automated alerts came sooner. Socket flagged plain-crypto-js@4.2.1 six minutes after it was published, before axios@1.14.1 existed, and flagged the LiteLLM wheels seven minutes after publication.

Read the chart as two populations, not a trend line. The long windows belong to quiet, targeted payloads. event-stream activated only inside one wallet's release build, and the xz backdoor only inside sshd on systems that linked it. The short windows belong to loud ones. A worm or a credential stealer that wants reach has to publish widely and fast, and fast publishing is exactly what publish-time scanners watch. ua-parser-js sits with the fast group even in 2021, and it dropped a cryptominer, which is about as loud as malware gets. The lesson is not that detection got better at everything. We see no evidence that a patient, targeted attacker is caught faster in 2026 than in 2024.

Short windows also do not mean small exposure. An install-time payload executes on the first fresh install, and CI fleets install continuously. A few hours of caret ranges resolving to axios@1.14.1 was enough to reach CI pipelines through npx and transitive ranges, as our analysis of the hidden blast radius of the axios compromise showed.

The npm timestamps above are reproducible. The registry keeps a version's publish time in the package document's time field even after the version itself is removed:

for spec in event-stream@3.3.6 ua-parser-js@0.7.29 chalk@5.6.1 \
            @ctrl/tinycolor@4.1.1 axios@1.14.1; do
  pkg=${spec%@*}; ver=${spec##*@}
  curl -s "https://registry.npmjs.org/${pkg/\//%2f}" |
    jq -r --arg p "$pkg" --arg v "$ver" \
      '[$p, $v, .time[$v], (.versions | has($v))] | @tsv'
done

Output on October 26, 2026. The last column says whether the registry still serves the version:

event-stream	3.3.6	2018-09-09T08:28:59.503Z	false
ua-parser-js	0.7.29	2021-10-22T12:15:21.378Z	false
chalk	5.6.1	2025-09-08T13:13:05.239Z	false
@ctrl/tinycolor	4.1.1	2025-09-15T19:52:46.624Z	false
axios	1.14.1	2026-03-31T00:21:58.168Z	false

The record has gaps. When npm replaces a whole package with a security placeholder, its history goes too: flatmap-stream, which carried the event-stream payload, now lists only two timestamps, from November 28 and 29, 2018, and none for the release that carried the payload. PyPI keeps less. On the same day, the JSON API for litellm 1.107.0 returned HTTP 404, and the release no longer appears in the project's version list. If you are reconstructing your own exposure after an incident, capture registry metadata while it still exists.

Software supply chain attacks are increasing because each successful one now funds the next. Four changes made that true.

One publish is a broadcast. The 19 packages hijacked in the Qix compromise receive 2 to 3 billion downloads a week combined. axios receives about 100 million. Few initial-access techniques give an attacker that many execution points for one stolen credential.

Stolen credentials compound. Install-time payloads run on exactly the machines that hold publishing credentials: developer laptops and CI runners. The Shai-Hulud worm of September 2025, the first known self-propagating npm worm, used the npm tokens it stole to republish itself into its victims' other packages. When Australian police arrested two alleged members of TeamPCP in August 2026, the Australian Federal Police estimated the group had enabled the theft of more than 500,000 credentials across more than a thousand organizations.

The tooling is public. In May 2026, TeamPCP released the worm's source code and co-launched a $1,000 BreachForums contest scored by the download counts of compromised packages. By mid-2026, multiple operators were running Shai-Hulud-style campaigns from the same code. A technique that once required a capable team now requires a forum account.

The attack surface moved into CI. Trusted publishing replaced long-lived npm tokens with short-lived OIDC credentials minted inside CI. Attackers followed the credential. The Mini Shai-Hulud wave that hit TanStack in May 2026 stole no long-lived npm token: attacker code ran inside TanStack's GitHub Actions workflow, read an OIDC token from runner memory, and published with valid Sigstore provenance. As Socket's TanStack analysis put it, "an attacker who can execute in GitHub Actions can generate valid Sigstore attestations for malicious packages."

AI agents add a fifth pressure. Coding agents install packages without a human reading the name. In September 2026, the UK AI Security Institute reported that GPT-6 Astra reached the payload-delivery stage of a supply chain attack in 29.2% of simulated capture-the-flag runs with OpenAI's cyber classifiers disabled. It had not been asked to attack open source.

We do not quote a headline count of attacks per year. Published tallies count packages, versions, or incidents, and are not comparable with each other. The defensible measure of the trend is the one above: the cost of an attack has fallen while its yield has risen. The OWASP Top 10 2025 reflects the same shift: it added Software Supply Chain Failures as a new category, ranked third.

You prevent a supply chain attack by breaking it at each of its three stages separately, because no single control touches all three. Every control below stops some rows of the incident table and misses others.

Four of these deserve detail.

A lockfile freezes what you already resolved. It does nothing for the next resolution, and checking one after an incident proves little. In the words of our axios follow-up, "Lockfiles make existing installs deterministic. They do not make new installs safe." Code fetched by npx or a global install never appears in a project lockfile at all.

A dependency cooldown refuses versions younger than a threshold. pnpm 11 defaults to 24 hours, npm added a minimum release age setting in its 11.x line, and Rust 1.100 is scheduled to add an opt-in Cargo setting on November 12, 2026. Every npm and PyPI attack in Figure 2 was reported or replaced within about four hours, long before a one-day delay would have let it install. A cooldown is useless against xz-style patience, and it delays security fixes unless you exempt them.

Package provenance proves which pipeline built an artifact, not that the pipeline was honest. Provenance and signatures are necessary but not sufficient. They still pay off when a policy checks them: the LiteLLM image's provenance recorded the lookalike repository Berri-AI/litellm, which a rule pinning the expected source would have rejected.

Behavior analysis reads what the artifact does instead of what its metadata claims. Socket Firewall applies it at fetch time: sfw wraps npm, pnpm, yarn, pip, uv, or cargo, filters their registry requests, and blocks package artifacts Socket has confirmed as malware. Its free tier warns on, but does not block, versions flagged by AI and not yet confirmed by a human, and it never sees packages served from a local cache.

Our verdict: consumers should run npm 12 or pnpm 10 and later, install from a committed lockfile with npm ci, set a release-age delay of at least 24 hours, pin CI actions to SHAs, and inspect everything a lockfile does not cover at fetch time. Publishers should remove long-lived tokens, require a human 2FA approval for each release, as npm's staged publishing does, and treat CI secrets as production credentials. None of this stops an attacker who already owns the supplier's organization.

The LiteLLM compromise shows where the remaining gap is. The malicious release was caught in minutes. The exposure that produced it lasted months: a leaked key sat unrevoked from May 2026, and attacker activity is documented from October 10.

Figure 3 lays out the sequence from LiteLLM's investigation and our follow-up. In May 2026, an Agent Platform master key was committed to a public repository and never revoked. On October 10 at 22:11 UTC, a push to a throwaway branch named ci-tmp-a351cc ran a workflow called cache.yml that posted six organization secrets, including GH_TOKEN, to a webhook.site collector. On October 12 at 12:16 UTC, a six-job version targeted 14 more secrets across five GitHub Environments. Each branch was deleted the day it was created. On October 21 at 10:51 UTC, the malicious release build started; its provenance recorded the source Berri-AI/litellm, and LiteLLM's audit logs tie the release approval to the token stolen on October 10. The seven 1.107.0 wheels reached PyPI at 11:39:51 UTC. Socket's AI scanner raised malware alerts at 11:46:30 UTC, seven minutes later, and Socket published its analysis at 13:41 UTC.

Registry-side detection now runs in minutes. Inside LiteLLM's own organization, the attacker worked undetected for at least 11 days, using access that traced back to a key exposed since May, and chose when to cash in. A push that runs a workflow on a branch deleted minutes later looks like routine CI to most organizations.

The next gain in supply chain security will not come from scanning releases faster. It will come from suppliers treating their CI secrets, org tokens, and release approvals with the audit trails and anomaly detection they already apply to production, because for everyone downstream, that is what they are.