Tens of millions of downloads of the popular Java logging library Log4j this year were vulnerable to a CVSS 10.0-rated vulnerability that first surfaced four years ago, according to Sonatype.
The security vendor claimed 13% of Log4j downloads in 2025 were still vulnerable to Log4Shell, hinting at the challenge of persistent risks in the open source ecosystem.
“On one side, there’s unfixed risk: vulnerabilities that never get patched upstream. On the other, there’s corrosive risk: vulnerabilities that do have fixes, but continue to spread because consumers don’t move,” it explained.
“The Log4j vulnerability – and the heavily used commons packages sitting alongside it – are now textbook examples of corrosive risk at scale.”
Sonatype compiled its analysis from Maven Central download data, revealing that 40 million of the 300 million Log4j downloads this year were buggy.
Among the countries with the largest developer populations, India (29%), China (28%) and Japan (22%) all recorded large shares of Log4Shell downloads. The US (9%), Brazil (8%) and France (8%) fared better, but still accounted for millions of avoidable vulnerable downloads, Sonatype claimed.
Read more on Log4Shell: Impact of Log4Shell Bug Was Overblown, Say Researchers
The issue is not confined to Log4j: Sonatype claimed that around 95% of downloads featuring vulnerable components have a safer version available, while only around 0.5% of components actually lack a fix.
The vendor claimed that developers continue to make these mistakes because of set-and-forget dependencies, transitive dependency blind spots and flawed criteria for choosing libraries that focus on popularity over security posture.
Security tools like software composition analysis (SCA) can make matters worse by flooding developers with alerts that lack actionable guidance, while product managers continue to be incentivized to prioritize time to market over security.
Eliminating Unnecessary Risk
Sonatype urged developers to stop pulling known-bad versions of components by:
- Using SCA tools and artifact repositories to understand how many downloads are vulnerable, which components show up in builds (and what versions) and which teams/apps/business units are responsible
- Changing how they select components, prioritizing security track record, active maintenance, governance and transparency
- Automating upgrade pull requests to safe versions, batching non-breaking upgrades regularly, autocompleting to safe versions in internal repositories and automatically alerting when someone tries to pull in a known vulnerable version
- Putting guardrails in place in artifact repositories and CI/CD pipelines to block downloads/use of known vulnerable versions for which a fix exists
- Adopting new metrics such as “unnecessary risk rate,” “fix adoption time” and “policy effectiveness”