According to Infosecurity Magazine, a new report from security vendor Sonatype reveals a massive ongoing security problem. The analysis of Maven Central download data shows that in 2025, a staggering 40 million downloads of the popular Log4j Java logging library were still vulnerable to the critical Log4Shell flaw. That represents 13% of the 300 million total Log4j downloads this year, despite a fix for the CVSS 10.0-rated vulnerability being available for four years. Countries with large developer populations like India (29%), China (28%), and Japan (22%) had particularly high shares of vulnerable downloads. The report also claims that around 95% of downloads with vulnerable components have a safer version available, blaming “set-and-forget” dependencies and flawed library selection criteria.
The Corrosive Risk Problem
Here’s the thing that really gets me about this report. It’s not just highlighting old bugs. It’s defining a whole category of failure they call “corrosive risk.” That’s the idea that a fix exists, but it just doesn’t matter because the bad version keeps spreading through dependency chains and inertia. And Log4Shell is now the poster child for this. We’re not talking about some obscure library no one maintains. This is one of the most fundamental pieces of the Java ecosystem. So if this is happening here, at this scale, what does it say about the millions of other dependencies out there? The report’s stat that only 0.5% of vulnerable components actually lack a fix is terrifying. The problem isn’t a lack of solutions. It’s a lack of action.
Why Nothing Gets Fixed
Sonatype points the finger at a few classic issues, and they’re all painfully familiar. “Set-and-forget” dependencies are basically the standard operating procedure. You add a library to your project, it works, and you never think about it again until something breaks. Then there are transitive dependency blind spots—where a vulnerable library is pulled in by another library you’re using, so it’s completely invisible to you. But I think the most damning point is about incentives. Developers are flooded with non-actionable alerts from security tools, and product managers are still rewarded for shipping features fast, not for updating old dependencies. So why would anyone prioritize this? It’s all downside with no visible upside until you’re breached.
A Systemic Ecosystem Failure
This isn’t just a developer education problem. This is a systemic failure in how we build and maintain software. The entire open-source supply chain model relies on millions of individual maintainers and consumers making good choices, but the tools and business pressures actively work against that. Look at the geographic data: massive rates in India and China. That likely points to the huge amount of new development and legacy enterprise code happening there, all pulling in these same old, vulnerable packages. The fix, as Sonatype suggests, is to stop pulling known-bad versions altogether—to shift the burden upstream. But that requires a level of coordination and tooling adoption that, frankly, seems miles away. Four years after Log4Shell, and we’re still here. That tells you everything you need to know about how hard this is to solve.
