Supply chain attacks, Mythos, Glasswing... and Echo

March 2026 reflected a massive shift in software supply chain stability – not because of a single headline breach, but because of how many things broke at once, and how clearly they were connected.

Within a matter of weeks, some of the most widely used open source tools in the world were compromised, including:

• Trivy, the standard for container vulnerability scanning
• LiteLLM, a unified API layer for LLMs, letting you call OpenAI, Anthropic, etc. with a single interface
• Axios, the default HTTP client for JavaScript embedded across millions of applications

It’s important to recognize that these aren’t edge tools or niche packages – they sit directly in the critical path of how software is built and run. And yet, each of them became a dangerous entry point.

How open source tools became software supply chain attack vectors

What made this moment different wasn’t just the severity of the attacks – it was the pattern. The same playbook kept on repeating itself: compromise a maintainer, publish a trusted update, let automated systems pull it everywhere, and quietly extract credentials at scale.

It wasn’t random. In fact, it was compounding.

The high-impact supply chain attacks that occurred in March each followed this exact model:

• Trivy (container security scanner) TeamPCP leveraged a previously poisoned GitHub Actions breach to exfiltrate CI/CD secrets, which they then used to compromise Trivy by force-pushing dozens of malicious GitHub Action tags along with a backdoored version (v0.69.4) of the Trivy binary. This version included a backdoor known as “Cloud Stealer,” which operated silently during normal scans – extracting AWS and GCP credentials, Kubernetes secrets, and environment variables, and exfiltrating them to a typosquatted domain (scan.aquasecurtiy[.]org).
• LiteLLM (PyPI) Access to a compromised LiteLLM maintainer was used to publish a malicious version of the package to PyPI, disguised as a legitimate update from a trusted source. With LiteLLM sitting between applications and providers like OpenAI and Anthropic, handling highly sensitive data such as API keys and routing logic, the malicious version executed automatically on Python startup and silently exfiltrated environment variables, cloud credentials, and API keys. And because it’s commonly used in production services with real credentials, the compromise exposed some of the most critical data paths in modern software systems.
• Axios (npm) Attackers targeted the Axios maintainer through a sophisticated social engineering campaign, using what appeared to be a legitimate Microsoft Teams update to gain access. They then used that access to publish a malicious version under the official Axios project, a foundational HTTP client used across most Node.js applications with ~100 million weekly downloads. Because Axios is an extremely common transitive dependency, the compromised version propagated silently into millions of environments, which allowed the malicious payload to run unnoticed – harvesting credentials and sensitive data, and creating a foothold for further downstream attacks leveraging those stolen secrets.

It’s worth noting that this trend didn’t begin in March as similar patterns were already emerging beforehand. In the case of Shai-Hulud (PyPI), for example, malicious packages executed code immediately upon installation, turning the install step itself into the attack vector. And attacks across the npm ecosystem before March targeted maintainers of high-download or single-maintainer packages, using credential theft to publish malicious versions directly to trusted repositories. Each of these incidents followed the same underlying logic. But more importantly, each one expanded the blast radius for the next.

Understanding the modern software supply chain attack chain

Today’s software supply chain attacks start with something small – a compromised maintainer account, a stolen token, a successful phishing attempt. From there, a trusted component is compromised. Because updates are automated and trust is implicit, the poisoned version spreads almost instantly across thousands of environments. Once inside, it does what attackers have always intended: harvest credentials, gain deeper access, and set up the next move.

And that’s the key shift: these attacks aren’t endpoints anymore, they’re multipliers.

Unfortunately, open source, as an ecosystem, is perfectly designed for this kind of propagation because it prioritizes speed, reuse, and distribution. Dependencies are layered on top of each other, updates are pulled automatically to keep pace with change, and maintainers are trusted by default. All of this is what makes modern development possible at scale.

But it’s also what makes coordinated attacks exponentially more powerful.

Why software supply chain attacks are increasing in 2026

Why are we seeing so many more attacks? Part of the answer is simple: open source has become the largest shared execution surface in the world. If you want reach, you don’t target individual companies – you target what they all depend on. The supply chain gives these attackers exactly that, while bypassing traditional security boundaries entirely.

But there’s another factor accelerating all of this: AI.

Code is being written faster than ever before. Teams are under pressure to ship quickly, automate aggressively, and move forward with fewer manual checkpoints. And this means fewer human eyes reviewing what actually gets pulled into production. Trust was always part of the system, but the speed at which that trust is exercised has changed. And it’s getting abused way faster.

Mythos, Glasswing, and the new reality of AI-driven vulnerability discovery

New AI systems like Mythos and Glasswing represent the most exciting, yet dangerous shift we’ve seen yet. AI models are no longer just helping developers move faster – they’re fundamentally changing how vulnerabilities are discovered and exploited.

They don’t just scan for known patterns – they can reason across entire systems, trace request flows, identify missing validations, and uncover escalation paths across multiple files. And they don’t stop at discovery – once a vulnerability is found, Mythos can generate a proof of concept, craft payloads, define execution steps, and continuously adapt until the exploit works.

In other words, it will keep going until it succeeds.

That power cuts both ways. On the one hand, we can finally eliminate classes of vulnerabilities that have existed for decades, like long-standing issues in core tools such as ffmpeg. Entire categories of vulnerabilities can now be identified and remediated faster than ever.

But we now also have the ability to discover and generate vulnerabilities at a scale the ecosystem has never handled. Zero-day discovery is no longer slow or manual – it’s becoming continuous, which creates a dangerous imbalance. We’re approaching a world where vulnerabilities can be found and exploited faster than the ecosystem can fix them.

That’s exactly why efforts like Glasswing are emerging: to help harden the ecosystem and coordinate defenses across package ecosystems, CI/CD platforms, cloud environments, and open source maintainers.

But coordination alone doesn’t solve the core constraint. Because you can’t coordinate your way out of a system that fundamentally struggles to apply and distribute fixes fast enough.

The biggest challenge in software supply chain security: fix propagation

For years, the bottleneck in security was finding vulnerabilities. That’s no longer the case. Discovery is scaling rapidly, and even fix generation is improving. But one part of the system hasn’t caught up at all: actually getting those fixes into production – which is where the real risk lives.

Because in practice, fixing a vulnerability is rarely straightforward. It’s not just applying a patch. It often means rebuilding components, dealing with breaking changes, resolving dependency conflicts, and validating everything across different environments – a process that takes an average of 80 days from when a fix becomes available. In fact, even when a fix exists upstream, there’s no guarantee it will ever reach the systems that need it.

So, you end up in a situation where the ecosystem technically moves forward, but your software doesn’t because the fixes exist, they just don’t propagate. At scale, that gap becomes the attack surface.

How Echo solves software supply chain risk at the source

The industry has spent the last decade optimizing for visibility – more scanning, more alerts, more dashboards. But visibility doesn’t fix problems. The underlying hard part has always been remediation, and more specifically, making sure fixes actually propagate across the ecosystem.

Because that’s the part of the process that’s messy. It involves rebuilding, testing, adapting, and continuously maintaining software across deeply interconnected systems. It doesn’t scale manually, and it doesn’t happen reliably. So while the ecosystem may technically move forward, what actually runs in production often doesn’t.

And in the Mythos and Glasswing era, this problem is becoming even more pronounced.

Vulnerability discovery is scaling exponentially. More issues will be found, and more fixes will technically exist, but the ability to apply and propagate those fixes isn’t keeping up. This creates a dangerous imbalance: companies end up running software that is theoretically patched upstream, but still vulnerable in practice.

The real risk isn’t just that vulnerabilities exist. It’s that fixes exist – and aren’t reaching you. And while Glasswing plays an important role in preparing and coordinating the ecosystem, without a system that ensures fixes actually propagate into production, we’ll continue to see the same pattern: components get fixed, while entire dependency trees remain exposed.

Echo’s approach: ensure fixes reach you by default

Echo is built to close this gap – not by adding more visibility, but by ensuring that fixes actually make it into the software people run. Instead of chasing patches, teams consume software that is already fixed, continuously updated, and hardened by default.

In practice, this looks like:

• Secure Images Ensures fixes reach you on time – before attackers do – without requiring you to rewire or rebuild anything yourself, while also minimizing the attack surface to only what’s necessary. You deploy images that are already fixed, hardened, and reduced to the smallest possible footprint.
• Secure Libraries (PyPI, npm, etc.) Prevents compromised or vulnerable components from entering your stack through fast, automated development flows where trust is implicit and verification is minimal. Rather than relying on the ecosystem blindly, you consume dependencies from a trusted, validated source.
• AI-powered Factory The engine behind everything – continuously monitoring for vulnerabilities, generating and applying fixes (including dependency rewrites where needed), and testing across each component and its entire dependency graph. Built for the AI era, it operates at the speed and scale required to make fix propagation real.

Why fix propagation matters most

What we’re seeing right now isn’t just a spike in attacks – it’s a structural shift in how software is built, distributed, and exploited. The ecosystem is becoming faster, more automated, and more interconnected, while trust remains implicit and fixing remains fragmented.

Glasswing is an important step toward preparing for this reality, but preparation alone won’t be enough if the software we all depend on continues to carry risk forward.

Because in a world where vulnerabilities are discovered and exploited faster than ever, the only thing that matters is whether the fix reach you before the attacker does.