If you follow software supply chain attack news today, one pattern dominates: attackers are compromising trusted open source packages on registries like npm and PyPI, and the newest campaigns can spread on their own without a human at the keyboard. Rather than breaking into a target directly, attackers poison a dependency the target already trusts and let the normal build process deliver the malware. That indirection is what makes these attacks so effective and so hard to notice.
This post steps back from any single headline to explain what a supply chain attack actually is, what the recent examples have in common, and what a defender should do about it.
What a supply chain attack is
A supply chain attack definition that holds up: it is an attack that reaches its target by compromising something the target depends on and trusts, rather than attacking the target head-on. In software, that "something" is usually a third-party package, a build tool, or a distribution channel. Your application pulls in hundreds or thousands of open source dependencies, most of them transitively, and every one is code you execute but did not write. Compromise any of them and you have a path in.
The leverage is enormous. Poison one popular package and you potentially reach every project that installs it, along with those projects' downstream users. That one-to-many amplification is why registries are such an attractive target.
The recent wave: self-propagating malware
The most notable shift in recent software supply chain attack news is self-propagation. Earlier campaigns were one-shot: publish a malicious package, harvest whatever secrets it could reach, done. The newer families reported through 2026, including the Shai-Hulud lineage and its variants, behave more like worms. Once malicious code runs on a developer's machine or in a CI pipeline, it hunts for credentials — npm and GitHub tokens, cloud keys, CI/CD secrets — and then uses those stolen tokens to publish trojanized versions of other packages the victim can access. Each compromise becomes a launch point for the next.
Reporting through 2026 has described multiple coordinated waves of this kind hitting both npm and PyPI simultaneously, affecting large package families across popular ecosystems and totaling hundreds of malicious package versions. The common thread across incidents is consistent: harvest secrets, then reuse those secrets to spread. The details of individual campaigns shift, but that mechanism is the story to understand.
A PyPI supply chain attack follows the same logic on the Python side. The registries differ, but the economics — one poisoned package, many downstream victims, stolen tokens fueling the next round — are identical.
How packages get compromised
Knowing the entry points tells you where to focus:
- Stolen maintainer credentials. A phished or leaked npm/PyPI token lets an attacker publish a malicious version of a legitimate package under the real maintainer's name. Self-propagating malware automates exactly this.
- Typosquatting. A malicious package named to resemble a popular one (a transposed letter, a hyphen) catches developers who mistype an install command.
- Dependency confusion. Publishing a public package with the same name as a company's private internal package, so a misconfigured build fetches the attacker's public version instead.
- Malicious install scripts. Package managers run lifecycle scripts on install. Code in a
postinstallhook executes on every machine that installs the package, before anyone has run the application.
Supply chain attack examples worth knowing
A few well-documented incidents illustrate the range, and studying supply chain attack examples is the fastest way to build intuition:
- event-stream (2018) — a popular npm package was handed to a new "maintainer" who quietly added code targeting a specific cryptocurrency wallet, buried in a transitive dependency. It ran for weeks before discovery.
- SolarWinds (2020) — attackers compromised the build system of a widely used IT management product and shipped a backdoor through a signed, legitimate software update to thousands of organizations. A supply chain attack that never touched a public registry at all.
- Codecov (2021) — a compromised CI script exfiltrated environment variables, including secrets, from customer build pipelines.
- The 2026 self-propagating campaigns — the worm-like npm and PyPI families described above, which represent the current state of the art in registry attacks.
Different mechanisms, same core idea: get into the supply chain and let trust do the delivery.
What actually defends against this
You cannot personally audit every line of every dependency, so defense is about visibility, constraint, and speed of response rather than perfect prevention.
Know what you actually depend on. You cannot defend a dependency you do not know you have, and most of your tree is transitive. Maintaining a real inventory — a software bill of materials (SBOM) — is the foundation. A software supply chain tool that performs software composition analysis resolves the full tree and matches it against known-malicious and vulnerable packages, so a compromised transitive dependency is visible instead of hidden. An SCA tool such as Safeguard can flag a poisoned package even when it sits several levels below your direct dependencies.
Pin and lock versions. Use a lockfile and pin exact versions so a malicious new release does not get pulled in automatically by a loose version range. Review dependency updates rather than auto-merging them, and be especially wary of a version that jumps unexpectedly.
Constrain install-time execution. Disable or sandbox lifecycle scripts where you can. Much registry malware relies on postinstall hooks running automatically; removing that automatic execution defangs a whole class of attacks.
Protect and scope credentials. Since the current worms spread by stealing and reusing tokens, short-lived and tightly scoped credentials limit the blast radius. A token that cannot publish packages cannot be used to spread the worm. Rotate anything that touches CI.
Watch the feeds and respond fast. Because these campaigns move quickly, the window between disclosure and your exposure is short. Following credible software supply chain attack news and wiring advisories into your alerting turns a scramble into a routine patch.
The takeaway
The headline changes weekly, but the shape does not. Attackers keep targeting the trust built into open source distribution, and the 2026 self-propagating families have made that trust more dangerous by turning each victim into a spreader. The defense is unglamorous and durable: know your full dependency tree, constrain what runs at install time, scope your secrets, and respond quickly. Teams that have those in place read the news as confirmation rather than crisis. The Academy has deeper material on building an SBOM-driven response process.
FAQ
What is a software supply chain attack?
It is an attack that reaches its target by compromising something the target trusts and depends on — a third-party package, build tool, or update channel — rather than attacking the target directly. In software, this most often means poisoning an open source dependency.
Why are npm and PyPI such common targets?
Because one compromised package can reach every project that installs it and everything downstream of those projects. That one-to-many amplification, combined with how much code teams pull in transitively, makes public registries high-leverage targets.
What makes the recent 2026 attacks different?
Recent campaigns are self-propagating. Once the malware runs, it steals credentials and uses them to publish trojanized versions of other packages the victim can access, so each compromise fuels the next — behaving more like a worm than a one-off poisoned package.
How do I protect my project from supply chain attacks?
Maintain a full inventory of your dependencies with software composition analysis, pin and review versions with a lockfile, disable or sandbox install-time scripts, scope and rotate credentials to limit blast radius, and wire security advisories into your alerting so you respond quickly.