Vulnerable Log4j Downloads persist, Signaling a Failed Supply Chain Security awakening
Despite the widespread alarm following the finding of the Log4Shell vulnerability in December 2021, a meaningful number of vulnerable Log4j downloads continue to occur in 2025, indicating that the software supply chain crisis hasn’t prompted the fundamental changes needed to secure critical infrastructure. The “internet on fire” headlines of late 2021 weren’t hyperbole, as security teams raced to address the flaw and governments issued mandates, briefly elevating software supply chain hygiene to a board-level concern.
According to research from Sonatype, roughly 13 percent of all Log4j downloads in 2025 were still for versions containing the Log4Shell vulnerability, even though safe iterations have been available for nearly four years. This translates to approximately 40 million downloads where organizations knowingly integrated a known risk into their systems.
The core issue has evolved beyond simply addressing open-source vulnerabilities; it’s now a problem of consumption and dependency management. “We aren’t just failing to patch-we are actively pulling broken components into new builds,” researchers noted. This pattern extends beyond Log4j, with Sonatype’s data revealing that approximately 95 percent of vulnerable components downloaded in 2025 already had safer versions available.Only 0.5 percent represented edge cases where no fix existed.
Researchers have termed this phenomenon “corrosive risk,” defining it as vulnerabilities with available fixes that continue to spread due to a lack of consumer action.This represents a massive and unneeded exposure, with the seven most frequently downloaded vulnerable components with fixes available accumulating over 3.324 billion downloads since the
Denial-of-Service. These platforms prioritize stability and rarely update low-level libraries due to performance concerns. Jdom2, a Java library for handling XML, illustrates a similar story, with the vulnerable version accounting for nearly 58% of downloads in 2025 – over 371 million pulls – despite a fix released in 2021 (version 2.0.6.1).
the persistence of these downloads begs the question: why aren’t available fixes being utilized? The answer lies in a combination of ingrained habits and misaligned incentives that accumulate as technical debt.”Transitive blind spots” are a major contributor, as developers often unknowingly use vulnerable components pulled in by other frameworks deep within the dependency tree, without direct visibility in build files. This creates an ownership vacuum where no team feels responsible for remediation.
Moreover, “inertia and ‘forever’ builds” contribute to the problem. Once a library is integrated and compiles, it tends to remain unchanged, with build files copied across services and versions pinned. Without dedicated ownership for dependency maintenance, these temporary choices become permanent fixtures. Existing security tooling often exacerbates the issue, generating overwhelming lists of CVEs without actionable guidance, leading to “alert fatigue” and developers dismissing the output as background noise.
While preventing all vulnerabilities in dependencies like Log4j is unrealistic, stopping the downloads of known vulnerable versions is achievable. Addressing this supply chain mess requires a shift from passive awareness to active control. teams must first “measure the mess” by using internal SCA tools to establish a baseline of vulnerable Log4j downloads in 2025, and prioritize closing any gaps compared to global averages.
Automation is crucial,with bots capable of opening upgrade pull requests for safe versions of Log4j and similar libraries. Batching these non-breaking upgrades into regular sprint work can transform them from panic-driven “patch weeks” into routine maintenance. Guardrails must be implemented at the source, with artifact repositories blocking or warning against known vulnerable versions and CI/CD pipelines failing builds that introduce banned versions.
organizations must “fix the incentives.” Currently, product managers are rewarded for hitting roadmap dates, not for prioritizing security hygiene. A redefinition of “good” performance is needed, measuring the reduction in “unnecessary risk” – the percentage of downloads that are vulnerable when a fixed version exists – rather then simply counting closed CVEs.
As the fifth anniversary of the Log4j vulnerability approaches, developers and organizations face a critical juncture. They can either become another statistic in the ongoing supply chain vulnerability crisis, or they can decide that unnecessary risk is no longer acceptable background noise.
