Software supply chain attacks: the 2024 to 2026 timeline and how to defend

What changed recently (1 November 2026): added the second LiteLLM compromise (21 October), the tensorlake release whose payload wipes your home directory when you revoke its stolen token (8 October), and the trojanized Claude Code extension on Cursor's marketplace (29 October).

A working reference, updated when a major incident lands. Every incident and number links to a source.

What is a software supply chain attack?

A software supply chain attack compromises something developers already trust, such as an open-source package, a CI action, a build pipeline or a vendor update, so malicious code reaches every downstream user without attacking them directly. ENISA calls it "a combination of at least two attacks": one on a supplier, then one on the target through it.¹ NIST: "an incident where an adversary exploits vulnerabilities in the product or service supply network of the intended target."²

How it works, in three steps

1. Compromise something upstream: a maintainer's account or laptop, a CI workflow, a publish token, a build server, or an unregistered package name.
2. Poison an artifact people already pull: a new package version, a GitHub Action tag moved to another commit, a rebuilt image, an extension update.
3. Let inherited trust run it. Version ranges, latest tags, auto-updates and CI install it without a human looking, with the permissions of a developer laptop or a build job that holds publish tokens and cloud keys.

How it differs from a vulnerability

A vulnerability is an accidental flaw in legitimate code. A supply chain attack delivers deliberately malicious code through a trusted channel, so you remove the version, treat every machine that ran it as compromised and rotate what it could read. MOVEit Transfer (2023) is often called a supply chain attack, but Cl0p exploited a zero-day (CVE-2023-34362) in widely used file-transfer software, and no supplier's code was altered.³ It was a supply chain problem only for organizations whose vendors ran MOVEit.

The term also covers commercial software updates: SolarWinds Orion (2020) shipped a digitally signed component carrying a backdoor and 3CX (2023) shipped trojanized installers,^4,5 and in 2025 Notepad++'s update traffic was hijacked through its hosting provider.⁶ This post focuses on open-source packages and CI, where engineering teams can act directly.

Supply chain attacks by the numbers (2025 to 2026)

Two warnings. Vendor counts measure different things (packages, versions, detections) over different windows, even across editions of the same report, so do not compute growth rates from them. And the often-quoted "45% of organizations will have experienced attacks on their software supply chains by 2025" is a Gartner prediction from March 2022, not a measurement.¹³

For defense, what matters most is how long a hijacked version stays installable. pnpm's maintainers, shipping their release-age setting: "In most cases, such attacks are discovered quickly and the malicious versions are removed from the registry within an hour."¹⁴ The timeline below mostly agrees.

Timeline: major software supply chain attacks, 2024 to 2026

Times are UTC. "Where it ran" is the point at which the malicious code executed on victims: at install, at import or interpreter start, inside CI, or at runtime in the application.

The pattern across the table: in 2025 and 2026 most large attacks did not rely on fake packages. They hijacked real ones, through a maintainer account or machine (axios, chalk, Mastra), a CI token (LiteLLM, Trivy), or the project's own release pipeline (TanStack, AsyncAPI, ChainDrop, tensorlake).

xz-utils backdoor (March 2024)

A contributor using the name Jia Tan joined xz in late 2021, was a maintainer within about 14 months, and in February and March 2024 released 5.6.0 and 5.6.1 with a backdoor in liblzma that let the key holder run commands through sshd on some Linux distributions.¹⁶ The payload sat in test files committed to Git; the build step that activated it existed only in the release tarballs. Andres Freund noticed slow SSH logins on Debian unstable and reported it on 29 March 2024, about five weeks after the first backdoored release and before most stable distributions shipped it.¹⁵ A cooldown does nothing against a patient insider; comparing published tarballs with the repository does.

tj-actions/changed-files (March 2025)

The chain started with a token leaked from the spotbugs project in December 2024, moved to reviewdog/action-setup on 11 March 2025, and reached tj-actions/changed-files on 14 March, when every tag of the action was repointed to a malicious commit.²¹ The payload read secrets from the runner process's memory and printed them, double base64-encoded, into the workflow logs, which anyone can read on a public repository. GitHub's advisory counts "over 23,000" repositories using the action.²⁰ Unit 42 says the attack initially targeted Coinbase's agentkit project. StepSecurity spotted it from an unexpected outbound connection on a monitored runner.⁵⁵ A tag is a pointer anyone with write access can move; a full commit SHA is not.

Worms: Shai-Hulud, Shai-Hulud 2.0 and ChainDrop (2025 to 2026)

Shai-Hulud (September 2025) was, per ReversingLabs, the first self-replicating npm worm. A postinstall script ran the TruffleHog secret scanner,²⁶ pushed what it found to a public GitHub repository named "Shai-Hulud", and used stolen npm tokens to publish infected versions of the victim's other packages. GitHub removed more than 500 packages.^27,28 Shai-Hulud 2.0 (November 2025) moved to a preinstall script that installed Bun and ran an obfuscated payload; Koi Security found it tries to destroy the home directory when it can neither steal a GitHub or npm token nor open an exfiltration channel.³⁰ Wiz counted about 700 to 800 packages and over 25,000 repositories.²⁹

The biggest 2026 wave was ChainDrop on 4 August. An attacker with the keyv maintainer's GitHub account pushed commits, and at 09:35 UTC the project's real release workflow published keyv 6.0.0 with genuine SLSA provenance.^46,47 A preinstall setup.mjs started the payload under Bun, which also committed .claude/settings.json SessionStart hooks and .vscode/tasks.json tasks to repository branches, so opening the project in Claude Code or VS Code runs it again.⁴⁶ Microsoft counts "more than 400 packages";⁴⁸ Aikido first posted 868, corrected it to 434 the same day and to 444 on 5 August, so both 868 and 444 circulate.^56,47

Elastic found the worm spreads only with npm tokens that have write permission and bypass 2FA.⁵⁷ npm restricted those tokens for account and package management on 31 July 2026, but they can still publish until npm's January 2027 target.⁵⁸ Microsoft notes the payload "contains a destructive handler if the monitored token is revoked".⁴⁸ The May TanStack wave had already used one.³⁷ In October, tensorlake (same setup.mjs and Math_Symbol.js loader as ChainDrop) carried a monitor that checks the stolen GitHub token every 60 seconds for up to 24 hours and runs rm -rf ~/ once GitHub rejects it.^50,46 Full playbook: protecting against Shai-Hulud-style npm worms.

Trivy, LiteLLM and the TeamPCP cascade (March 2026), and LiteLLM again (October 2026)

In late February 2026 an automated account exploited a pull_request_target workflow in Trivy's repository and stole a token.⁵⁹ Aqua's rotation after the 1 March disclosure "was not atomic", so the attacker kept access. On 19 March the attacker published trivy v0.69.4 through the real release pipeline and force-pushed 76 of 77 tags of aquasecurity/trivy-action and all 7 of setup-trivy to commits that dumped the CI runner's memory for secrets.³² The attacker calls itself TeamPCP, per Wiz.⁶⁰ The campaign continued: CanisterWorm on npm from 20 March, which Aikido calls "a direct follow-up from the attack on Trivy" (its initial list named 47 packages);⁶¹ Checkmarx's GitHub Actions and Open VSX extensions on 23 March, through access Checkmarx traces to the Trivy attack;⁶² LiteLLM on 24 March; and the Telnyx SDK on 27 March, published with a PyPI token Endor Labs believes the LiteLLM payload harvested.⁶³

LiteLLM believes its compromise "originated from the Trivy dependency" in its CI. Versions 1.82.7 and 1.82.8 appear to have been uploaded straight to PyPI, bypassing CI, and were live "for about 40 minutes" from 10:39 UTC before quarantine; other published timelines are wider.³³ 1.82.8 added litellm_init.pth, and Python runs import lines in .pth files at every interpreter start, "regardless of whether a particular module is actually going to be used".³⁴ It was found because the file caused a fork bomb on a FutureSearch developer's machine, where litellm was a transitive dependency of an MCP plugin.⁶⁴

On 21 October LiteLLM was compromised again. The attacker held GitHub CLI tokens of an organization owner and two maintainers, used the owner's to override branch protection, and pointed the release workflow at a lookalike repository, Berri-AI/litellm. Seven malicious 1.107.0 wheels reached PyPI at 11:39 to 11:40 UTC, and PyPI quarantined the release at 13:23.⁵² The payload (cook.pth, sitecustomize.py) runs on every Python start, and the malicious Docker images carry a valid signature from LiteLLM's previous cosign key. LiteLLM recommends pinning 1.106.2.⁵¹

axios (31 March 2026)

axios 1.14.1 was published at 00:21 UTC and 0.30.4 around 01:00; both were removed at 03:15, "about 3 hours" later.³⁵ The axios source was unchanged. The only difference was a new dependency, plain-crypto-js@^4.2.1, whose postinstall script installed a remote access trojan on macOS, Windows and Linux. A clean 4.2.0, published about 18 hours earlier, apparently gave the name some history; Socket's automated detection flagged 4.2.1 about six minutes after it appeared.^35,65 The post-mortem says to downgrade to 1.14.0 (or 0.30.3).³⁵

The lead maintainer's post-mortem says the attacker reached the maintainer's PC "through a targeted social engineering campaign and RAT malware" two weeks earlier: a cloned company founder, a Slack workspace, then a Teams call in which the maintainer was told something on the system was out of date. 2FA was enabled; with a trojan on the machine it did not matter.³⁵ The malicious versions came from the maintainer's personal account; the post-mortem says the OIDC publishing flow the project is now adopting "should have been in place before this happened".^35,65 Google attributes the attack to UNC1069, a North Korea-nexus group, and Microsoft to Sapphire Sleet, which it calls a North Korean state actor; Google counts over 100 million weekly downloads for axios 1.x, Microsoft over 70 million.^66,67 In June npm added a 72-hour read-only hold for high-impact accounts that change their email or use a recovery code, citing the pattern in which "a compromised account changes its email, mints a new token, and publishes malicious versions".⁶⁸

TanStack (11 May 2026)

A fork's pull request ran in a pull_request_target bundle-size workflow and saved a poisoned pnpm store into the Actions cache under a key the release workflow would restore. When that workflow ran, attacker code read its OIDC token from the runner's memory and published 84 versions of 42 packages at 19:20 and 19:26 UTC. TanStack: "No npm tokens were stolen and the npm publish workflow itself was not compromised." The publishes went through TanStack's own trusted-publisher binding, and the versions carried valid SLSA provenance.^36,69 The payload ran from the prepare script of a Git dependency added through optionalDependencies; it was public within 20 to 26 minutes and fully deprecated at 21:03.³⁶ The wave reached over 170 npm and PyPI packages, according to OX Security; on PyPI, mistralai 2.4.6 ran its code on import, and guardrails-ai 0.10.1 carried the same malware.^38,37 The npm payload also installed a gh-token-monitor that checks a stolen GitHub token every 60 seconds for up to 24 hours and tries to run rm -rf ~/ if the token is revoked.^70,37 Wiz attributes the wave to TeamPCP "with high confidence".⁷⁰

The damage travelled. A Nx contributor installed a malicious @tanstack package because the pinned pnpm 10.14 silently ignored the project's 7-day release-age setting; the malware used the contributor's GitHub CLI token "within 74 seconds", and a malicious Nx Console extension shipped on 18 May.³⁹ GitHub later said an employee's device was compromised through a poisoned VS Code extension, and that the attacker's claim of about 3,800 exfiltrated internal repositories was "directionally consistent" with its investigation.^71,40

Before 2024: the landmark cases

event-stream (npm, 2018): the author handed the module to a volunteer who asked to maintain it, and the volunteer added a dependency, flatmap-stream, whose payload only activated inside the Copay bitcoin wallet's build.^72,73 SolarWinds (2020): a build-time implant put the SUNBURST backdoor into a signed Orion component; "fewer than 18,000" customers may have installed it, and the White House counted 9 federal agencies and about 100 companies compromised.^74,4,75,76 Codecov (2021): its Bash Uploader script, altered periodically from 31 January, exposed customers' CI environment data to an attacker until a customer noticed a checksum mismatch on 1 April.⁷⁷ 3CX (2023): a trojanized X_TRADER installer, downloaded from Trading Technologies' own website onto an employee's personal computer, led to trojanized 3CX installers,⁷⁸ "the first time Mandiant has seen a software supply chain attack lead to another software supply chain attack".⁵

Types of software supply chain attacks

Where malicious code runs: npm, PyPI, crates.io, Go, RubyGems, Packagist

Which defenses work depends on when a package's code first runs on your machine, and that differs by registry.

npm is still the main target (over 99% of open-source malware in Sonatype's 2025 data); the npm supply chain attacks guide covers npm-specific attack types and defenses in depth.

Why provenance, 2FA and --ignore-scripts were not enough in 2026

Provenance proves where a package was built, not that the build was honest

Several 2026 malicious releases came from the victim's own pipeline, so their provenance was real. Microsoft on AsyncAPI: "All five malicious versions were published through npm trusted publishing using GitHub OIDC and carried valid provenance attestations."⁴⁵ Datadog on keyv 6.0.0: the provenance was "neither forged nor a safety verdict".⁴⁶ TanStack's and tensorlake's malicious releases also came from their own release workflows,^36,50 and LiteLLM 1.107.0's images carried the project's own signature.⁵¹ Provenance still helps as a signal the other way: a release that suddenly lacks the provenance its predecessors carried deserves a look, and pnpm's trustPolicy: no-downgrade fails an install when a package's trust level drops.¹⁰⁰

2FA stops phishing, not a compromised machine or a bypass token

In 2025 lookalike domains phished maintainers: a fake 2FA-reset email from npmjs.help for chalk and debug, pypj.org on PyPI.^25,101 Phishing-resistant passkeys defeat that, and npm has been phasing out TOTP in their favor since September 2025.¹⁰² They do not help when the attacker controls the maintainer's machine (axios) or holds a 2FA-bypass token, which the worms spread with. After the @antv wave in May 2026, Microsoft reported that GitHub invalidated 61,274 npm granular tokens with write access and 2FA bypass.¹⁰³

Disabling install scripts removes one entry point, not all of them

Install hooks are still the most common entry point, and npm 12 blocks dependency lifecycle scripts and implicit node-gyp builds unless approved.⁸⁴ But AsyncAPI's payload "executes at module-load (import/require) time", and Microsoft says plainly not to rely on --ignore-scripts.⁴⁵ Python .pth files run at interpreter start (LiteLLM), Composer autoload on every request (Laravel-Lang) and Go init() at program start. For code that runs on import, the only checks are reading it or not installing that version yet.

A cooldown only works if your tools apply it

The Nx contributor had a 7-day release-age setting, but "pnpm 10.14 silently ignores the unknown config key".³⁹ pnpm 12 now reports unrecognized settings.¹⁰⁴ Cooldowns also do nothing for moved tags (tj-actions, trivy-action), since no new version is released; SHA pinning covers that.

How to prevent software supply chain attacks

Teams that install dependencies

1. Install exactly what the lockfile says. Commit lockfiles and install with npm ci, pnpm install --frozen-lockfile or the equivalent. CISA's May 2026 alert: "Pin software to specific trusted versions."⁴⁰
2. Wait before adopting new releases. CISA says to "wait at least three hours before pulling a new package";⁴⁰ three days covers every hijacked release in the timeline above that was pulled within a day. The settings, by tool:

   # .npmrc (npm 11.10.0 or later; the value is in days)
   min-release-age=3
   
   # pnpm-workspace.yaml (the value is in minutes; pnpm 11 defaults to 1440)
   minimumReleaseAge: 4320
   trustPolicy: no-downgrade
   
   # pyproject.toml (uv)
   [tool.uv]
   exclude-newer = "P3D"
   
   # pip
   pip install --uploaded-prior-to P3D -r requirements.txt

   Units differ: days for npm,⁸⁵ minutes for pnpm (default 1440),^100,105 ISO 8601 durations for uv¹⁰⁶ and pip (pip needs upload times from the index).¹⁰⁷ Bun takes seconds (minimumReleaseAge = 259200 under [install] is 3 days),¹⁰⁸ and Yarn 4.10+ has npmMinimalAgeGate.¹⁰⁹ Then confirm your installed version honors the setting.
3. Delay update PRs too. Dependabot's cooldown and Renovate's minimumReleaseAge:^110,111

   # .github/dependabot.yml
   version: 2
   updates:
     - package-ecosystem: "npm"
       directory: "/"
       schedule:
         interval: "weekly"
       cooldown:
         default-days: 3
   
   // renovate.json
   { "minimumReleaseAge": "3 days" }

4. Allow-list install scripts. npm 12 runs no dependency install scripts by default: npm approve-scripts --allow-scripts-pending lists what is waiting, and npm approve-scripts <pkg> adds a version-pinned entry to the allowScripts field of package.json, which you commit.^84,112 On older npm, set ignore-scripts=true (details). pnpm 11 runs no dependency build scripts unless listed in allowBuilds.¹⁰⁵
5. Keep Git and URL dependencies off. npm 12 defaults --allow-git and --allow-remote to none;⁸⁴ pnpm 11 turns on blockExoticSubdeps by default.¹⁰⁵
6. Know what you run. Keep an SBOM or searchable lockfiles so "are we affected?" takes minutes, turn on Dependabot malware alerts for npm,¹¹³ and review the code of new and changed dependencies.

CI pipelines

1. Pin actions to full commit SHAs, and turn on the GitHub policy that fails workflows using unpinned actions.¹¹⁴ Pins are not transitive: trivy-action pins older than April 2025 still pulled the malicious setup-trivy.³²

   permissions:
     contents: read
   jobs:
     test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@<full 40-character commit SHA> # vX.Y.Z
           with:
             persist-credentials: false
         - run: npm ci

2. Never run pull-request code in a privileged context. GitHub has narrowed pull_request_target: it always uses the default branch's workflow,¹¹⁵ actions/checkout refuses common pwn-request patterns,¹¹⁶ and untrusted triggers get a read-only cache.¹¹⁷ The checkout guard does not cover run: steps that fetch PR code with git or gh, or triggers such as issue_comment, and it can be switched off. Do not give AI agents in workflows shell access on anyone's input (Cline).³¹
3. Keep secrets away from installs. No publish tokens or cloud keys in the install job, minimal permissions, no cache restores in release workflows.
4. Watch egress. tj-actions was caught from an unexpected outbound connection on a runner.⁵⁵
5. Rotate atomically and inventory every token: Trivy's rotation was "not atomic", and Cline deleted the wrong token.^32,31

Maintainers who publish packages

1. Publish with trusted publishing (OIDC) on npm, PyPI, crates.io and RubyGems, and delete long-lived tokens; a leftover token gave Ultralytics its second round.¹⁸ Scope the publisher to one workflow and a protected environment with required reviewers: SAP's @cap-js packages were published because the configuration covered the whole repository.¹¹⁸ npm now rejects trusted-publishing tokens minted from issue_comment events.¹¹⁹
2. Require a human approval to release. npm's staged publishing holds a version until a maintainer approves it with 2FA.⁸⁷
3. Use passkeys, and treat GitHub CLI tokens on laptops as publish credentials: they were the way in for Nx Console and LiteLLM in October.^39,51
4. Remove people who no longer maintain the package. Mastra's attacker used a former contributor's account.⁴⁴
5. Protect release branches and use immutable releases, which do not freeze existing Action tags.^120,32

What to do if you installed a compromised version

1. Confirm exposure. Search lockfiles (and their history), images and CI caches for the exact versions, and check the vendor's indicators. For LiteLLM 1.107.0, LiteLLM lists cook.pth, sitecustomize.py and a lock file at /tmp/remote_code_loader.lock, and warns that not finding them "does not prove the environment is clean".⁵¹
2. Isolate the machine or runner first. Take it off the network before revoking anything, and keep it off until step 3 is done: someone else may revoke the token meanwhile, and the wiper fires on its next check.
3. Disarm persistence before you revoke anything. For the tensorlake and ChainDrop family, StepSecurity's advice is "Don't revoke any GitHub token" until the token monitor is stopped and deleted, because revocation triggers rm -rf ~/.^50,48 It runs as the systemd user service gh-token-monitor.service on Linux, the LaunchAgent ~/Library/LaunchAgents/com.user.gh-token-monitor.plist on macOS, or a logon task running monitor.ps1 on Windows. Stop it, then delete ~/.config/gh-token-monitor, ~/.local/bin/gh-token-monitor.sh and the service file or LaunchAgent plist.⁵⁰ Also look for .claude/settings.json and .vscode/tasks.json hooks committed to your repositories.⁴⁶
4. Rotate everything the machine or job could read, from a clean machine: npm, PyPI and GitHub tokens (including GitHub CLI logins), cloud and Kubernetes credentials, SSH keys and AI API keys.^48,40,57
5. Purge caches and rebuild. Clear package-manager caches (Microsoft names npm and Yarn; do the same for pnpm and pip), shared CI caches, base images and runner images.⁴⁸
6. Hunt across your GitHub organization for public repositories you did not create (descriptions such as "Sha1-Hulud: The Second Coming" or "Shai-Hulud: Here We Go Again"), self-hosted runners named SHA1HULUD, unfamiliar workflow files such as .github/workflows/discussion.yaml, and commits by claude@users.noreply.github.com titled "chore: update dependencies".^29,30,50
7. Pin the last good version, and reinstall the machine if you cannot be sure it is clean.⁵⁰

Where source-level review fits

Advisory tools (npm audit, Dependabot, OSV) only know a malicious version after someone reports it; reading the code works before that. In Togoder Security an AI model reads the source code of every package version in your lockfile across npm, PyPI, crates.io, Go, RubyGems and Packagist, without running it, and flags behavior such as credential reads, unexpected network calls, obfuscated payloads and code that runs on import. Use the web upload or the API, including from CI (how), from a prepaid balance or with a monthly plan.

It complements cooldowns and pinning, and AI review has false positives and can miss things; the methodology explains verdicts and limits. Identical files get one verdict, which saves work: in our corpus of 1,661 npm and Go package versions hashed on 4 to 6 October 2026, about one in five code files was byte-identical to another file already in the corpus.