Ongoing vulnerable Log4j downloads suggest the supply chain crisis wasn’t the wake-up call it should have been.
Back in December 2021, the “internet on fire” headlines weren’t hyperbole. Security teams scrambled, governments issued mandates, and for a moment, software supply chain hygiene became a board-level priority. Yet, as we move through 2025, a stubborn baseline of vulnerable Log4j downloads simply won’t disappear.
According to Sonatype, roughly 13 percent of all Log4j downloads in 2025 were still for versions featuring the Log4Shell vulnerability; despite safe iterations being available for nearly four years. That’s about 40 million downloads where teams effectively opted into a known risk.
The issue isn’t fundamentally about open-source vulnerability anymore; it is a consumption and dependency-management problem. We aren’t just failing to patch—we are actively pulling broken components into new builds.
Not just a Log4j hangover
Sonatype’s research highlights the downloads aren’t just a hangover from the Log4j vulnerability. When you look at the broader ecosystem, the same pattern plays out: about 95 percent of vulnerable components downloaded in 2025 already had a safer version available. Only 0.5 percent were edge cases where no fix existed.
Researchers call this “corrosive risk” (i.e. vulnerabilities that have fixes but continue to spread because consumers don’t move.) It’s a massive volume of unnecessary exposure. The seven most frequently downloaded vulnerable components with fixes available have been downloaded more than 3.324 billion times this year or since their patches were released.
The risk isn’t spread evenly across the globe. To see who is actually patching, researchers analysed download patterns in the ten countries with the largest developer populations.
Asian markets currently sit at the high end of vulnerable consumption: India (29%), China (28%), and Japan (22%) are still pulling in Log4Shell-vulnerable versions at worrying rates. But Western teams shouldn’t get too comfortable. The US (9%), Brazil (8%), and France (8%) might perform better comparatively, but they are still shipping millions of avoidable vulnerable downloads.
The concerning fact? Not one of these major software-producing nations is close to zero.
Silent culprits in the supply chain
While the Log4j vulnerability got the press, other component downloads are arguably more insidious because they fail quietly. They are the “set-and-forget” libraries that underpin enterprise infrastructure.
Take commons-lang, for instance. Version 2.6 is a legacy major version replaced by commons-lang3 over a decade ago. It contains a severe uncontrolled recursion vulnerability (CVE-2025-48924). Yet, in the months following the fix’s publication in July 2025, researchers observed more than 155 million vulnerable downloads (99.88% of the total for that component.)
The problem is the upgrade path. Moving from 2.6 to 3.x isn’t a simple drop-in replacement; it requires extensive code refactoring. Large, older enterprise systems depend on the 2.x line and cannot practically migrate to the incompatible 3.x API, so they keep downloading the vulnerable version.
Then there is Snappy (0.4). This compression library is widely embedded in massive distributed systems like Hadoop, HBase, and Spark. These platforms pin their dependencies for stability and rarely update low-level libraries due to performance concerns. Consequently, 99.58 percent of downloads are still for the vulnerable 0.4 version, exposing systems to a memory-handling flaw (CVE-2024-36124) that can lead to Denial-of-Service.
Jdom2 tells a similar story. This popular Java library for handling XML was fixed in 2021 (version 2.0.6.1) to prevent “Billion Laughs” XML expansion attacks. Yet, the vulnerable version accounted for nearly 58 percent of downloads in 2025—over 371 million pulls.
Why downloads of vulnerable versions of Log4j remain high
If the fixes to these supply chain vulnerabilities exist, why don’t we use them? The reasons are often habits and misaligned incentives that pile up as technical debt:
- Transitive blind spots: Developers often don’t even know they are using these components. Many vulnerable libraries arrive transitively, pulled in by other frameworks deep in the dependency tree. They never appear in a pom.xml or build.gradle file directly, creating an ownership vacuum where no specific team feels responsible for the remediation.
- Inertia and “forever” builds: Once a library is wired in and compiles, it tends to stay there. Build files get copied from service to service, and versions get pinned. Without an explicit owner for dependency maintenance, these “temporary” choices become permanent fixtures.
- Noisy tools: Security tooling often makes things worse. Many SCA tools scream about every CVE with equal volume, generating long lists without actionable guidance like “upgrade to version X.Y.Z”. The result is alert fatigue. Developers treat the output as background noise rather than a navigational aid.
We can’t stop vulnerabilities in dependencies like Log4j from ever appearing, but we can stop downloads of the ones we already know about. Cleaning up this supply chain mess requires shifting from passive “awareness” to active control.
- Measure the mess: You can’t fix what you don’t track. Teams need to use their internal SCA tools to get a baseline: what percentage of Log4j downloads in 2025 were vulnerable? If your internal stats look worse than the global averages, closing that gap is the immediate priority.
- Automate the grunt work: Relying on developers to manually check for library updates is a losing strategy. Automation should handle the easy parts; bots can open upgrade PRs for safe versions of Log4j and similar libraries. Batching these non-breaking upgrades on a regular cadence makes them part of normal sprint work rather than a panic-driven “patch week”.
- Stop the bleeding at the source: Suggestions aren’t enough; you need guardrails where the downloads of dependencies like Log4j actually happen. Artifact repositories should block or warn against known vulnerable versions when a fix exists. CI/CD pipelines should fail builds that introduce new uses of banned versions, preventing the worst offenders from creeping back in.
- Fix the incentives: Finally, stop punishing security hygiene. Product managers are currently rewarded for hitting roadmap dates, not for spending a sprint upgrading logging libraries. We need to redefine “good” performance. Instead of counting raw CVEs closed, measure the reduction in “unnecessary risk” (i.e. the percentage of downloads that are vulnerable when a fixed version exists.)
The fifth anniversary of the Log4j vulnerability is approaching. By then, developers and organisations can either become another statistic from supply chain vulnerabilities, or they can decide that unnecessary risk is no longer acceptable background noise.
See also: Sonatype Guide brings DevSecOps to AI coding
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.