Log4Shell was supposed to be the wake-up call that changed everything. Four years later, the data says otherwise.
In 2025, developers pulled Log4j from Maven Central nearly 300 million times. Roughly 13% of those downloads — about 40 million — still contained Log4Shell, even though safe versions have been available for almost four years.
And Log4j is just the tip of the iceberg.
When Sonatype's researchers zoomed out across the broader ecosystem in the 10th Annual State of the Software Supply Chain Report®, the same pattern kept appearing: about 95% of vulnerable components downloaded already had a safer version available, while only around 0.5% truly lacked a fix. In other words, the vast majority of this risk is avoidable.
It's not that open source is inherently unsafe. It's that we keep choosing unsafe versions even when better ones exist.
To understand where this is happening, Sonatype Security Research analyzed 2025 Log4j download patterns and a handful of heavily used Java components with known vulnerabilities and available fixes.
A few highlights:
Ten countries with the largest developer populations — China, the United States, India, Japan, Brazil, Germany, the United Kingdom, Canada, South Korea, and France — together represent more than 14 million developers. Not one of them is close to zero avoidable vulnerable downloads.
In these countries, anywhere from 8% to 29% of Log4j downloads in 2025 still contained Log4Shell.
Beyond Log4j, a set of frequently downloaded Java components with known CVEs and available fixes have been pulled more than 2.94 billion times this year or since their patches were released (whichever is more recent).
Every one of those billions of downloads represents unnecessary risk: teams pulling vulnerable versions when fixed ones already exist, and in some cases have for years.
Log4Shell made headlines as the "internet on fire," sparked SBOM mandates, and accelerated regulation like NIS2 and the CRA. But the fire never completely went out.
Our latest research shows a stubborn baseline of vulnerable Log4j downloads and massive ongoing use of other vulnerable components, even as new critical issues emerge — such as the recently disclosed React2Shell vulnerabilities — and AI-driven development accelerates dependency sprawl.
Taken together, Log4j and these "sticky" Java components are textbook examples of persistent, corrosive risk: vulnerabilities that do have fixes, but continue to spread because consumers don't move.
The reasons are rarely dramatic. They're mostly habits and incentives:
Set-and-forget dependencies that no one revisits once they compile.
Transitive dependencies that sneak in through frameworks and libraries, with unclear ownership.
Flawed selection signals, where stars and Stack Overflow answers matter more than fix history or security posture.
Tools that shriek but don't steer, generating noisy CVE lists without clear "upgrade to X.Y.Z" guidance.
Incentives that undervalue hygiene, rewarding features shipped, not vulnerable libraries quietly removed.
The result: vulnerable versions of Log4j, commons-* packages, snappy, jdom2, and more keep getting pulled into new builds long after safer versions exist.
We've pulled the key findings into a new infographic:
Country-by-country rates of vulnerable Log4j downloads in 2025
The most overused vulnerable Java components and how often teams are still choosing unsafe versions
Read the Report and then run your own numbers: scan for Log4j and these frequently downloaded vulnerable components, calculate what share of their usage is still vulnerable, and benchmark your "unnecessary risk rate" against the trends in our research.
Log4Shell doesn't have to be an annual anniversary. It can be the moment you stop treating avoidable risk as background noise — and start choosing less of it.