The State of Open Source Supply Chain Attacks - StepSecurity

Customers

Pricing

Resources

Company

Request a Demo<br>Login

Customers

Pricing

Resources

Company

Start Free

Login

Back to Blog

Threat Intel

The State of Open Source Supply Chain Attacks

56 supply chain attacks in 12 months, each with a StepSecurity Threat Center alert. The data, the worms, the Team PCP numbers, and how to defend.

Varun Sharma<br>View LinkedIn

August 22, 2026

Share on X<br>Share on X<br>Share on LinkedIn<br>Share on Facebook<br>Follow our RSS feed

Table of Contents

Loading nav...

Security teams keep asking us the same question: how often do software supply chain attacks actually happen? Not in theory. In practice, this year, against real packages and real CI/CD pipelines.

We can answer that question with our own data. Over the last 12 months, the StepSecurity threat intelligence team tracked and alerted on 56 distinct supply chain attacks. Every one of them is a real compromise: a package on npm, PyPI, RubyGems, Composer, or crates.io that shipped malware, a GitHub Action whose tags were poisoned, or a popular IDE extension that shipped a new, compromised version built to steal credentials. For every incident in this report, a Threat Center alert went out to StepSecurity customers. This report puts all 56 on one timeline, and the trend is not subtle.

What this report counts: malicious, not vulnerable

Before the numbers, one definition matters. Every incident in this report is a malicious compromise, deliberately planted code, not a vulnerability. A vulnerable package is an honest mistake, a flaw an attacker might exploit later, in production, if the affected code path is even reachable. Log4j is the classic example. A malicious package is the attack itself. It runs the moment a developer machine or CI runner installs it, steals credentials right there, and never needs to reach production at all. Vulnerability disclosures such as CVE analyses are excluded from every count in this report, and so are suspicious events that were never confirmed as compromises, such as unexplained tag movement in a popular GitHub Action that turned out to be benign.

One more exclusion matters. Registries see a constant stream of brand new packages that are malicious from their first version: typosquats, name confusion packages, and lookalikes that never earn anyone's trust. Those are not counted here either. The attacks that cause real damage, and the 56 in this report, target components that organizations and developers already trusted. The attacker compromises the next version of a trusted package, or an existing version where the ecosystem allows tags to be silently repointed, and rides that existing trust straight into thousands of builds.

Finally, these incidents are not just blog posts. Every incident counted in this report shipped as a real time alert in the StepSecurity Threat Center, with indicators of compromise and an automated am I affected check, so every customer knew within hours whether they were exposed. A few of these incidents were covered as Threat Center alerts without a standalone blog post, and they are counted here all the same.

The distinction matters for defense, not just bookkeeping. Traditional software composition analysis watches what is deployed in production, which is the right place to look for vulnerabilities, because production is where a vulnerability can be exploited. It is far too late a place to look for malicious code. By the time a malicious dependency reaches production, it has already run on a laptop or in a pipeline and the credentials are already gone.

The attack rate, month by month

Here is every month from August 2025 through August 2026, with the number of distinct supply chain attacks we confirmed and alerted customers on.

Through February 2026, a confirmed supply chain attack was roughly a monthly event. In March 2026 the rate jumped to 13 incidents in a single month and has stayed high since: 9 in April, 9 in May, 10 in June, 6 in July. That is roughly 9 attacks per month, or about one every three days.

The acceleration, in one comparison

Split the year in half and the shift is stark. In the six months from August 2025 through January 2026, we tracked 6 incidents. In the six and a half months since February 2026, we tracked 50. That is more than an 8x increase from the first half of this 12 month period to the second.

What changed: attacks became worms

The single biggest driver of the acceleration is self propagation. In September 2025, the Shai-Hulud worm compromised more than 500 npm packages by using each victim's stolen npm token to infect the packages they maintained. It was the first supply chain attack that spread on its own at ecosystem scale. It was not the last.

Sha1-Hulud, the second coming hit Zapier, ENS Domains, and other prominent npm packages in November 2025, and was later detected inside CNCF's Backstage repository.

CanisterWorm spread backdoors across npm in March...