Log4Shell (CVE-2021-44228): Millions of Applications Remain Unpatched Two Years Later

December 9 marks the second anniversary of a cybersecurity alert that sent shockwaves through the digital world: the discovery of Log4Shell, a critical zero-day vulnerability within Apache Log4j. With a severity rating of 10.0, it was a stark reminder of the ever-present dangers lurking in widely used open-source software. At the time, Veracode estimated that 88 percent of organizations used Apache Log4j, making its impact unprecedented.

This vulnerability (CVE-2021-44228) in Log4j versions 2.0-beta9 to 2.15.0 allowed for remote code execution (RCE) attacks, posing a serious threat to affected servers. The response was a colossal effort to patch systems worldwide, estimated in the hundreds of millions. The ‘apocalypse‘ many feared didn’t materialize, but the U.S. Department of Homeland Security’s Cyber Safety Review Board predicted a decade-long journey to fully remediate CVE-2021-44228.

The anniversary of Log4Shell provides an ideal opportunity to reassess the state of Log4j vulnerabilities and the broader impact on open-source software security. Veracode’s recent analysis of 38,278 unique applications over 90 days revealed concerning insights:

• More than one-third of applications still use vulnerable versions of Log4j. A troubling 2.8 percent continue to operate with the original Log4Shell vulnerabilities.
• Despite initial efforts to patch Log4Shell, 3.8 percent of applications run Log4j2 2.17.0, which, while patched against Log4Shell, contains another high-severity RCE vulnerability (CVE-2021-44832).
• A significant 32 percent of applications use Log4j2 1.2.x, an end-of-life version with no ongoing support, making them susceptible to numerous critical vulnerabilities.

The initial response to Log4Shell was commendable, but it merely scratched the surface of a much deeper issue in open-source software security. The prevalence of vulnerable Log4j versions is a testament to the ongoing challenge in this domain. This is further supported by Veracode’s State of Software Security (SOSS) v11 Open Source Edition research, which highlights that 79 percent of developers do not update third-party libraries post-integration.

The reluctance for major version upgrades, due to compatibility and resource constraints, often leaves applications stranded on outdated versions like Log4j 1.2.17. While minor version updates are less disruptive, they do not address the underlying security gaps, as evident in the Log4j scenario.

Interestingly, when developers are alerted to vulnerabilities, they tend to act quickly – with 50 percent of flaws being addressed within 89 days. This contradicts the slow remediation observed in Log4j 1.2.x, hinting at deeper issues like resource constraints and lack of contextual understanding.

Log4j exemplifies the risks inherent in open-source software, with implications for operational security and IT health. Recent SEC regulations and the National Cybersecurity Strategy emphasize the critical nature of securing open-source software.

At the time Log4Shell emerged, Veracode CTO Chris Wysopal stated, “Log4j created awareness that you should have as much security testing automation in build processes as possible. It was also a wake-up call to how security technical debt, when left unaddressed, can cause urgent issues to take an enormous amount of time to fix.”

The Log4Shell anniversary is not just a milestone but a reminder. The journey to secure open-source software is ongoing, requiring constant vigilance, improved practices, and a proactive approach to software security.