Software Supply Chain Attacks: 113 Real Examples

Updated 9 Oct 2026

113 case records, from 2009 to today. Every one arrived as a normal update from a source the world already trusted. Most had no CVE on day one.

Each attack has its own page with the affected versions, the sources, how to check your machine and what Vigilance shows on the poisoned release.

Recent supply chain attacks (2026)

These are the 19 supply chain attacks from 2026 in the library, newest first.

The most famous supply chain attacks

These cases have documented broad impact. The list is not a severity ranking.

113 entries

npm attacks

PyPI attacks

GitHub Actions attacks

Vendor binary attacks

Browser and IDE extension attacks

Other ecosystems: crates.io, RubyGems, Maven, NuGet and source tarballs

Why supply chain attacks are hard to defend against

A supply chain attack is hard to stop because the bad code comes from a source you already trust. It arrives as a normal update. It often carries a valid signature, and it often has no CVE on the day it ships.

A scanner that looks for known bad code has nothing to match at that point. A file integrity tool sees that a file changed, but every update changes files. The question that matters is what the new version can do that the old one could not.

That is the question Vigilance answers. It compares the version you trust with the new one and names the file that gained a new capability. Read how to prevent supply chain attacks for the controls that work.

Frequently asked questions

What is an example of a supply chain attack?

The axios npm attack in March 2026 is one example. An attacker took over a maintainer account and published axios 1.14.1 and 0.30.4. Those versions added a new dependency that installed a remote access trojan. This library holds 113 more examples, each with its own page.

What is the most famous supply chain attack?

The SolarWinds Orion attack of 2020 is the most widely reported. A backdoor called SUNBURST shipped inside signed Orion updates to thousands of customers. Other well-known cases are NotPetya through M.E.Doc in 2017, CCleaner in 2017, 3CX in 2023 and the xz Utils backdoor in 2024.

Why are supply chain attacks difficult to defend against?

The malicious code arrives as a normal update from a source you already trust. It is often signed, it often has no CVE on the day it ships, and a scanner that looks for known bad code has nothing to match yet.

One entry here is a captured run on the real packages. The rest are rebuilt from public reports, in the words Vigilance prints, because the malicious releases are not redistributed. Not every supply chain attack works this way. Some change a value rather than a capability, and some never touch a file on your machine.