The Supply Chain Attack Playbook: Why Package Ecosystems Keep Getting Compromised

Four major supply chain attacks in six months. LiteLLM on PyPI, Shai-Hulud across hundreds of npm packages, the qix compromise, and now axios. Each one proving the same point: maintainer accounts are single points of failure in systems designed for trust, not adversaries.

The recent axios compromise was textbook. A hijacked maintainer account turned the JavaScript HTTP client with 100M+ weekly downloads into a RAT delivery mechanism for three hours. Pre-staged infrastructure, platform-specific payloads for macOS/Windows/Linux, self-deleting malware that erased its traces after execution. Sophisticated, patient, and completely preventable with basic hygiene.

But this isn't about axios. It's about a pattern that's now hitting every major package ecosystem — and why we keep making the same mistakes.

‍

The Attack Pattern is Universal

Whether it's npm, PyPI, RubyGems, or Crates.io, the playbook never changes:

1. Compromise maintainer credentials through phishing, credential reuse, or social engineering
2. Publish malicious versions directly to the registry, bypassing source control entirely
3. Let ecosystem trust do the rest — users pull updates automatically, CI systems resolve to latest versions
4. Clean up and disappear before anyone notices

The axios attack followed this exactly. The attacker compromised @jasonsaayman's npm account, changed the email to an anonymous ProtonMail address, and published malicious versions that had no corresponding git tags or commits. The packages existed only on the registry, invisible to anyone checking the source repository.

LiteLLM on PyPI used the same approach weeks earlier. So did the broader Shai-Hulud campaign that poisoned hundreds of packages. The infrastructure changes, but the fundamental vulnerability is identical: package registries treat maintainer accounts as sufficient authority to publish, regardless of whether the code passed through normal release workflows.

‍

The Human Problem Behind the Technical Problem

Here's what nobody talks about: maintainers are drowning. They're managing thousands of GitHub notifications, triaging security alerts with no budget for fixes, and wading through AI-generated PRs that look helpful but require manual review to verify. A single popular package maintainer might get 50+ AI-generated contribution attempts per week — each one requiring time to evaluate, most adding no real value.

Meanwhile, enterprises extract millions in value from these packages while contributing nothing back. No funding, no security review, no maintenance support. Just demands for faster fixes and compatibility with their internal systems.

When you're burned out and overwhelmed, you make mistakes. You reuse passwords across accounts. You skip 2FA setup because it's "one more thing." You fall for sophisticated phishing because you're processing hundreds of legitimate-looking emails per day. We've made maintainer accounts single points of failure while making maintainer lives systematically unsustainable.

‍

The Economics Are Completely Broken

The incentive structure underlying open source is fundamentally misaligned with security requirements. A maintainer can spend years building critical infrastructure used by millions of applications, then get attacked when security issues emerge. They bear all the liability with none of the compensation.

Companies treat open source as "free" rather than "someone else is paying the cost." They build their entire technology stack on volunteer labor, then act surprised when that labor becomes a security vulnerability.

Consider the numbers: axios serves 100 million downloads per week. If just 1% of those downloads came from organizations paying $1/month for maintenance, that's $1M annually to support the maintainer. Instead, we have a single volunteer managing infrastructure that thousands of companies depend on, with no compensation and increasingly sophisticated attackers targeting their personal accounts.

‍

What Actually Works

The organizations surviving these incidents have learned to assume trust will fail. They've implemented controls that limit blast radius when (not if) maintainer accounts get compromised:

Lockfile enforcement across all ecosystems. Using npm ci, pip install --no-deps, poetry install --only=main, or equivalent commands that install exactly what's specified, not what's latest. A committed lockfile would have stopped axios for most teams.

Script execution controls. Disabling postinstall hooks via --ignore-scripts flags in CI environments prevents malware execution entirely. The axios RAT never would have run.

Dependency pinning. Exact versions instead of ranges (1.14.0 not ^1.14.0) prevent silent upgrades to malicious releases.

Provenance verification. Requiring cryptographic attestations that link packages back to specific source control commits and build runs.

But technical controls only solve half the problem. The other half is supporting the humans maintaining the code we depend on.

‍

Making Maintainer Sustainability Part of Security Strategy

This is why HeroDevs launched our $20 million Open Source Sustainability Fund. We can't secure the supply chain without securing the maintainers. When projects we support through Never-Ending Support reach end-of-life, we fund the original maintainers and contribute security patches upstream. When we identify critical vulnerabilities in widely-used packages, we fund the fixes rather than just filing issues.

This isn't charity — it's infrastructure investment. Every dollar spent supporting maintainers prevents multiple incidents downstream. Every security patch we fund upstream protects thousands of projects that depend on that code. When maintainers have sustainable funding, they can implement proper security practices instead of choosing between paying rent and maintaining 2FA.

The axios incident will generate dozens of blog posts about detection tools and scanning techniques. But the real lesson isn't technical — it's economic. We need to stop treating maintainer sustainability and supply chain security as separate problems. They're the same problem wearing different hats.

‍

The Pattern Will Continue Until We Fix the Root Cause

Package registries have become critical infrastructure for modern software development, but they're built on 1990s assumptions about trust and volunteer labor. Every registry operates the same way: if you have valid credentials, you can publish anything. No verification that the code matches the source repository. No checks that the release went through normal workflows. No validation that the person publishing is actually the person who wrote the code.

Meanwhile, the attackers are getting more sophisticated. The axios compromise wasn't script-kiddie opportunism — it was professionally planned and executed, with 18-hour infrastructure pre-staging and custom RATs for three operating systems. These aren't random hackers anymore. They're organized operations that understand exactly how our trust-based systems work and where they're vulnerable.

Until we address both the technical architecture (better registry security, mandatory provenance checks, attestation requirements) and the economic foundation (sustainable maintainer funding, professional security support), we'll keep seeing the same attacks with different package names.

‍

What's Your Plan for the Next One?

If you're an engineering leader, ask yourself: what happens when the next critical dependency gets compromised? Not just for detection and response, but for supporting the maintainers whose accounts are your single points of failure.

Do you know which of your dependencies are maintained by volunteers working nights and weekends? Do you contribute funding to the projects your business depends on? Do you have incident response plans that assume maintainer account compromise rather than hope for better scanning tools?

The axios attack is already over. The next one is already being planned. The question isn't whether it will happen — it's whether you'll be ready when it does.

At HeroDevs, we work with companies dealing with both sides of this equation: securing active dependencies and maintaining abandoned ones. The solution isn't more scanning or faster alerts — it's building resilience into the system itself. Learn more about our approach.