Supply chain attacks how one compromised package affects millions

[EventHorizon25]

TL;DR

• A software supply chain attack compromises something many others depend on, such as a vendor update, an open source package or a build system, so one breach spreads to thousands of victims
• Landmark cases include SolarWinds (disclosed December 2020), the xz utils backdoor (March 2024), the September 2025 npm compromises including the Shai-Hulud worm, and the March 2026 axios package compromise
• Attackers increasingly target maintainers directly through phishing and stolen tokens, then publish malicious versions that install automatically through loose version ranges
• Defences include pinning and lockfiles, delaying brand new releases, disabling install scripts where possible, trusted publishing with provenance, SBOMs and frameworks such as SLSA
• Regulation is raising the bar: the EU Cyber Resilience Act's vulnerability reporting duties began on 11 September 2026

Why supply chains are such attractive targets

Modern software is assembled rather than written from scratch. A typical application depends on hundreds or thousands of open source packages, commercial libraries, build tools, container images and cloud services. Each of those components has its own maintainers, infrastructure and dependencies. Together they form a vast, interconnected supply chain

For attackers, this structure offers enormous leverage. Compromising one popular component can deliver malicious code to every organisation that uses it, often automatically through routine updates. Instead of breaking into thousands of targets one by one, an attacker breaks into one supplier and lets trust do the rest. That efficiency explains why supply chain attacks have become one of the defining threats of the past decade

This thread explains how supply chain attacks work, walks through landmark cases and sets out practical defences for developers, organisations and open source maintainers. It aims to be useful whether you write code, buy software or simply want to understand the headlines. The tone is constructive, because the community has made real progress in response. Many of the tools now available did not exist five years ago

How supply chain attacks work

There are several common patterns. Attackers may compromise a vendor's build system so that legitimate, signed updates contain hidden malware. They may take over a maintainer's account on a package registry and publish a malicious version. They may slowly gain trust in an open source project and introduce a backdoor themselves, or they may publish lookalike packages with names similar to popular ones, a technique called typosquatting

Automatic updates amplify the damage. Many projects specify dependencies with version ranges, such as accepting any compatible minor release. When a malicious version appears that fits the range, the next install pulls it in without anyone deciding to upgrade. Install scripts, which some package managers run automatically, can then execute the attacker's code on developer machines and build servers

Developer machines and continuous integration systems are particularly valuable targets. They often hold credentials for cloud accounts, code repositories and package registries. Malware that steals those secrets can spread further, publishing more malicious packages or reaching production systems. Some recent attacks have been designed explicitly as worms that propagate this way

Landmark cases

SolarWinds remains the archetype. In December 2020, investigators revealed that attackers had inserted a backdoor, later named SUNBURST, into updates for SolarWinds' Orion network monitoring software. Around 18,000 customers installed the compromised updates, although the attackers then chose a much smaller number of high value targets, including US government agencies, for further exploitation. The US government attributed the operation to Russia's foreign intelligence service

Other incidents broadened understanding. The Kaseya VSA attack in July 2021 used a managed service provider tool to spread ransomware to hundreds of downstream businesses. In 2023, the 3CX desktop app compromise was traced to an earlier supply chain compromise of different software installed by a 3CX employee, a cascading attack. The same year, exploitation of the MOVEit file transfer software by the Cl0p group exposed data from thousands of organisations that used it or relied on suppliers who did

The xz utils backdoor, discovered in March 2024, showed patience on a remarkable scale. Over roughly two years, a contributor using the name Jia Tan built trust in the small but widely used compression project, became a maintainer and inserted a sophisticated backdoor targeting SSH on some Linux distributions. Microsoft engineer Andres Freund noticed unusual SSH login delays and investigated, uncovering the backdoor before it reached most stable releases. The case, tracked as CVE-2024-3094, highlighted how much critical infrastructure depends on a few overstretched volunteers

The npm wave of 2025 and 2026

The JavaScript ecosystem experienced a series of major compromises from 2025 onwards. In September 2025, a prominent maintainer was tricked by a phishing email, and attackers published malicious versions of popular packages including chalk and debug, which together had billions of weekly downloads. The malicious code targeted cryptocurrency transactions in browsers. Quick community detection limited the damage, but the scale of potential exposure was startling

Days later, a self replicating worm dubbed Shai-Hulud spread through npm. It stole developer credentials from infected machines and used them to publish infected versions of other packages those developers maintained, compromising hundreds of packages. A larger second wave followed in November 2025. In response, GitHub, which operates npm, announced tighter controls on publishing tokens and authentication

On 31 March 2026, two versions of axios, a JavaScript HTTP library with more than 100 million weekly downloads, were published to npm with a remote access trojan delivered through a malicious dependency. The releases appeared to come from a hijacked maintainer account and did not match the project's official release tags. Security scanners flagged the malicious dependency within minutes, and the versions were deprecated, but projects using loose version ranges could have pulled them in automatically. Further worm style compromises affecting hundreds of package versions were reported later in 2026

These incidents share lessons. Maintainer accounts and tokens are high value targets, install scripts provide an easy execution path, and loose version ranges let malicious releases spread silently. Detection by security companies and alert developers is often fast, measured in minutes or hours. The challenge is that even a short window can reach many systems

Not every supply chain incident is an attack

Supply chain risk includes accidents. On 19 July 2024, a faulty content update from security vendor CrowdStrike caused around 8.5 million Windows computers to crash, disrupting airlines, hospitals, banks and broadcasters worldwide. No attacker was involved, yet the impact rivalled major cyberattacks. The event showed how deeply organisations depend on a small number of widely deployed vendors

Vulnerabilities in widely used components create similar exposure. Log4Shell, disclosed in December 2021, was a critical flaw in the Log4j Java logging library, used in countless products. Organisations spent weeks simply working out where they were affected. That experience accelerated demand for software bills of materials

Defences for developers and teams

Pin dependencies and use lockfiles so that builds use exactly the versions you have reviewed. Update deliberately rather than automatically, ideally through tools that open pull requests you can review. Many teams now wait a few days before adopting brand new releases, since malicious versions are often detected quickly. Some package managers support a minimum release age setting for this purpose

Reduce what runs at install time. Where possible, disable automatic install scripts or allow them only for packages that need them. Some newer package managers skip install scripts by default. This single change blocks a common execution path for malicious packages

Protect developer and build credentials. Use short lived tokens, enforce multi factor authentication on registry and code hosting accounts, and avoid storing long lived secrets on developer machines. Separate build environments from personal workstations. Treat continuous integration systems as production infrastructure, because attackers do

Verify what you consume. Check package provenance where registries support it, review new dependencies before adding them, and use software composition analysis tools that flag known malicious or vulnerable packages. Be cautious with packages suggested by AI coding assistants, which sometimes recommend names that do not exist. Attackers register those names hoping someone installs them

Defences for maintainers and publishers

Maintainers carry a heavy responsibility, often as volunteers. The most impactful steps are enabling phishing resistant multi factor authentication on registry and code hosting accounts and using trusted publishing, which lets continuous integration systems publish packages using short lived identity tokens instead of long lived secrets. Registries including npm and the Python Package Index support trusted publishing, and npm can attach provenance statements linking a package to the source and build that produced it. These measures make account takeover far less useful to attackers

Signing and transparency tools help too. Sigstore provides free signing and transparency logs for open source artefacts, and the SLSA framework, short for Supply chain Levels for Software Artifacts, defines increasing levels of build integrity. OpenSSF Scorecard checks projects against security best practices automatically. Adopting even the first levels of these frameworks raises the bar significantly

Finally, maintainers deserve support. Organisations that depend on open source can fund maintainers, contribute security work and participate in foundations such as the Open Source Security Foundation. Sustainable funding reduces the burnout that social engineering attacks like xz exploit. Healthy communities are a security control in their own right

Defences for buyers and organisations

Ask suppliers for a software bill of materials, or SBOM, listing the components in their products. SBOMs became a policy priority after US Executive Order 14028 in 2021 and are increasingly expected in contracts. They let you answer the question of whether you are affected by a newly disclosed vulnerability in hours rather than weeks. Pair them with processes to act on the information

Assess vendors' secure development practices, update processes and incident response capabilities. Frameworks such as the NIST Secure Software Development Framework provide useful questions. Design for resilience too, with staged rollouts of updates, the ability to roll back quickly and contingency plans if a critical vendor fails. The CrowdStrike outage showed the value of all three

Regulation is reinforcing these expectations. The EU Cyber Resilience Act requires manufacturers of products with digital elements to manage vulnerabilities throughout the product lifecycle, and its obligations to report actively exploited vulnerabilities and severe incidents began on 11 September 2026, with most other requirements applying from December 2027. Organisations selling into Europe need to understand their components well to comply. Supply chain security has become a legal duty as well as good practice

A quick checklist

• Pin dependencies, use lockfiles and update through reviewed pull requests
• Delay adoption of brand new releases by a few days where practical
• Disable or restrict install scripts
• Use short lived credentials, phishing resistant MFA and trusted publishing
• Check provenance and scan dependencies for known malicious or vulnerable packages
• Maintain SBOMs and ask suppliers for theirs
• Plan staged rollouts and rollback for critical vendor updates
• Support the open source maintainers you depend on

Closing thoughts

Supply chain attacks exploit the trust that makes modern software possible. They will not disappear, because the efficiency that attracts attackers is the same efficiency that lets developers build quickly. The good news is that the defences are maturing rapidly, from trusted publishing and provenance to SBOMs and regulation. Every team that adopts them makes the whole ecosystem safer

If you have handled a supply chain incident or improved your own pipeline, please share what you learned below. Practical configuration tips are especially welcome. Remember to strip any sensitive details before posting


Key references for citation

• CISA and partners, guidance on the SolarWinds Orion compromise, 2020 to 2021
• CVE-2024-3094, xz utils backdoor, March 2024
• GitHub, npm security changes following the Shai-Hulud attacks, 2025
• InfoQ, report on the axios npm compromise, April 2026
• SLSA framework (slsa.dev); Sigstore (sigstore.dev); OpenSSF Scorecard
• EU Cyber Resilience Act, Regulation (EU) 2024/2847