The State of Open Source Supply Chain Attacks

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 2026.
• Smaller mini Shai-Hulud variants kept appearing, hitting SAP related packages in April, then TanStack packages and the AntV ecosystem in May.
• The Miasma worm forced Microsoft to disable the Azure Functions Action and 72 other repositories in June 2026, and resurfaced in July inside the AsyncAPI ecosystem.
• ChainDrop arrived in August 2026 as a Bun loaded npm worm that harvests CI/CD credentials and uses an Ethereum smart contract as a dead drop for its command and control address.

A worm changes the math. One phished maintainer no longer means one compromised package. It means every package that maintainer can publish, then every package those downstream victims can publish.

What one attacker took: the Team PCP numbers

Volume tells you attacks are frequent. The Team PCP campaign tells you what a single campaign costs.

In March 2026, the threat actor Team PCP ran a five day campaign, March 19 to 24, built on a simple loop: compromise a widely trusted component, plant a credential stealer, collect the secrets that CI/CD runners load into memory, and reinvest those credentials into the next compromise. The components they poisoned included the Trivy GitHub Action (76 of its 77 version tags), the Checkmarx KICS Action, the telnyx PyPI package (with the stealer hidden in a WAV audio file), and LiteLLM, one of the most widely used AI infrastructure packages.

In August 2026, CloudSEK's threat intelligence team published the victim dataset, and we analyzed it. The totals from those five days:

The victims span every major CI/CD platform. This was not a GitHub problem or a GitLab problem. It was a build system problem.

And the stolen material was exactly what an attacker needs to go deeper: cloud keys, signing keys, and the tokens that control source code itself.

One actor. Five days. That is what a supply chain attack means in 2026.

Team PCP was not alone in that window. The same month brought a broader wave of credential stealing compromises, including axios, a package with over 100 million weekly downloads. Malicious versions axios@1.14.1 and axios@0.30.4 pulled in a fake dependency that dropped a cross platform remote access trojan on install, called home to the attacker's server, and then erased its own traces. StepSecurity's AI Package Analyst flagged the release, and Harden-Runner captured the live C2 callback during a GitHub Actions run in CNCF's Backstage repository, evidence the malware tried to delete.

The blast radius per incident is growing too

The frequency chart understates the problem, because individual incidents got bigger over the year. These six incidents show the scale a single compromise now reaches.

Add intercom-client, a package with 361,000 weekly downloads hijacked in April 2026, and the pattern is clear: attackers now go straight for the components with the largest downstream reach.

No ecosystem is exempt

A year ago, supply chain attack mostly meant npm. npm is still the biggest target, but our last 12 months of incident reports span every channel developers pull code from.

Highlights beyond npm: Microsoft's durabletask package was compromised on PyPI, SleeperGem backdoored git_credential_manager and fastlane RubyGems, the Laravel-Lang attack rewrote every tag across multiple Composer packages, and arrayref, internment, and append-only-vec brought build time droppers to Rust crates just this week.

AI is now part of the story on both sides. hackerbot-claw, an AI powered bot, actively exploited GitHub Actions at Microsoft, Datadog, and CNCF projects, and the Miasma worm specifically targeted AI coding agents. If your organization ships software, at least one of these channels is in your build.

GitHub Actions is a primary target

One pattern deserves its own section, because it showed up all year in three distinct forms: attackers going after the credentials that live in GitHub Actions.

The first form attacks the Actions themselves. Version tags on GitHub Actions are mutable references, so an attacker who compromises a maintainer account can repoint every existing tag to malicious code, and every workflow that uses the Action picks it up on the next run with no change in any repository. That is exactly what happened to the Trivy Action (76 of 77 tags), Checkmarx KICS, actions-cool/issues-helper, codfish/semantic-release-action, simonecorsi/mawesome, and xygeni-action. Alongside them, hackerbot-claw, an AI powered bot, actively exploited workflow vulnerabilities at Microsoft, Datadog, and CNCF projects.

The second form goes straight for the runner itself, riding in on compromised packages. Many of the packages in this report carried payloads built specifically for CI: the moment a build job installed the poisoned version, the malware dumped the credentials sitting in the GitHub Actions runner’s worker process memory, then exfiltrated them to the attacker. The Shai-Hulud family, the Team PCP stealers, and ChainDrop all worked this way, and it is why a package compromise on npm or PyPI so often ends with stolen CI/CD credentials. Harden-Runner blocks this class of attack automatically: with an egress policy in place, the credential dump has nowhere to go, because the runner refuses the outbound connection to the attacker’s endpoint.

The third form turns stolen developer credentials into a harvesting operation. Once an attacker compromises a developer’s GitHub credentials, often stolen from their machine by one of the packages above, they push a new workflow file on a new branch across every repository that developer can access. Each planted workflow runs immediately and exfiltrates the secrets available to that repository’s pipelines. The Miasma worm spread exactly this way, planting workflows with stolen credentials until Microsoft had to disable 73 repositories, and the Hades campaign used the same pattern. StepSecurity ships a secret exfiltration policy as part of workflow run policies: when this pattern is observed, the workflow is automatically blocked from running.

Why the attacks keep working

Across all 56 incidents, the same three weaknesses appear again and again. None of them are exotic. All three are fixable.

What to do with these numbers

If you are building the internal case for supply chain security, the one year summary is:

• 56 confirmed supply chain attacks in 12 months, each with a Threat Center alert, indicators of compromise, and an automated am I affected check for customers
• Roughly one attack every three days since March 2026, up from roughly one per month a year ago
• A single five day campaign stole 78,330 secrets from 2,186 organizations, including 92 public companies worth a combined $6.2 trillion
• Self propagating worms are now routine, so each incident compounds instead of staying contained
• Every major package ecosystem and CI/CD platform has been hit

How StepSecurity turns every attack into a stronger defense

At StepSecurity, our philosophy is to treat every supply chain attack as a test case for the product. Each incident in this report was run against our platform, and whatever gap it exposed became the next control. A year of that loop, at one attack every three days, is why the platform now prevents, detects, and responds across the three surfaces these attacks actually target: developer machines, code repositories, and CI/CD pipelines.

See it in action. The interactive demos below walk through the controls that map to the attacks in this report.

Two layers run underneath all three surfaces. Secure Registry sits between your environment and the public registries, blocking compromised and typosquatted packages before they reach a laptop or a runner. And the Threat Center, powered by the same threat intelligence team behind this report, delivers an alert with indicators of compromise and an automated am I affected check for every incident, which is how each of the 56 attacks in this report reached our customers within hours. From there, search spans every exposure surface at once: developer machines, and code repositories across both the default branch and open pull requests, because a malicious dependency in a pull request has already run in CI even if it never merges.

None of this is a lab claim. Through the community tier that protects over 10,000 open source projects, Harden-Runner detected the Sha1-Hulud worm inside CNCF's Backstage repository and captured the axios remote access trojan's C2 callback live, evidence the malware was built to erase.