State of Log4j Vulnerabilities: How Much Did Log4Shell Change?

December 9 marks two years since the world went on high alert because of what was deemed one of the most critical zero-day vulnerabilities ever: Log4Shell. The vulnerability that carried the highest possible severity rating (10.0) was in Apache Log4j, an ubiquitous Java logging framework that Veracode estimated at the time was used in 88 percent of organizations. 

If exploited, the zero-day vulnerability (CVE-2021-44228) in Log4j versions Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) would allow attackers to perform a remote code execution (RCE) attack and compromise the affected server. 

It triggered a massive effort to patch affected systems, estimated to be in the hundreds of millions. The apocalypse that many feared didn’t happen, but given its pervasiveness, the U.S. Department of Homeland Security’s Cyber Safety Review Board determined that fully remediating Log4Shell would take a decade. 

The two-year anniversary of Log4Shell is a good opportunity to examine the state of Log4j vulnerabilities and assess how the lessons learned improved the state of open-source software security. To do so, Veracode analyzed data from software scans over 90 days between August 15 and November 15, 2023 for 38,278 unique applications running Log4j versions 1.1 through 3.0.0-alpha1 across 3,866 organizations. 

What we found illustrates how unaddressed security technical debt exposes organizations to numerous risks. 

The Takeaways 

Overall, we found that more than 1 in 3 (38 percent) of applications currently use vulnerable versions of Log4j. This breaks down as follows: 

• 2.8 percent of applications are still using versions of Log4j with the Log4Shell vulnerabilities (Log4j2 2.0-beta9 through 2.15.0) 

• 3.8 percent of applications are still using Log4j2 2.17.0, which is patched against the Log4Shell vulnerability but contains CVE-2021-44832. This is a high severity RCE vulnerability that allows an attacker with privilege to modify logging configuration to send malicious configuration via JDBC Appender with a data source referencing a JNDI URI. The surprising prevalence of vulnerable applications running 2.17.0 may be because teams reacted quickly to patch the initial Log4Shell vulnerability but then reverted to previous behavior of not patching even after the release of 2.17.1 and beyond. 

• 32 percent of applications are using Log4j2 1.2.x, a version that reached end-of-life in August 2015 and therefore is no longer supported with patches. In January 2022, Apache announced three critical vulnerabilities affecting this version, CVE-2022-23307, CVE-2022-23305 and CVE-2022-23302. These brought the total number of high and critical vulnerabilities published since Log4j 1.2.x reached end-of-life to seven. 

Analysis 

At a surface level, the numbers above show that the massive effort to remediate the Log4Shell vulnerability was effective in mitigating risk of exploitation of the zero-day vulnerability. That should not be surprising. 

The bigger story at the two-year anniversary, however, is that there is still room for improvement when it comes to open-source software security. If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open-source security practices, the fact that more than 1 in 3 applications currently run vulnerable versions of Log4j shows there is more work to do. The major takeaway here is that organizations may not be aware of how much open-source security risk they are exposed to and how to mitigate it.

We explored this issue extensively in our recent State of Software Security (SOSS) v11 Open Source Edition research.

In that study, we found that 79 percent of the time, developers never update third-party libraries after including them in a code base. This helps explain why such a large percentage of applications are running an end-of-life version of Log4j.

Major version upgrades (e.g. 1.x to 2.x) can be expensive for developers because of the difficulty in maintaining backwards compatibility (even though 65 percent of open-source library updates are minor version changes or smaller and therefore unlikely to break the functionality of even the most complex application). 

This means that developers typically will just upgrade to the highest minor version (which is 1.2.17 for the 1.x series) because that can usually be done in just a few minutes without application code changes. Log4j's official upgrade guide provides a good idea of how much work it is to upgrade from 1.2 to 2.x. 

Our research also found that once developers are alerted to a vulnerable library through a scan, they fix them relatively quickly: 50 percent of vulnerabilities are fixed in 89 days overall, in 65 days for high severity vulnerabilities and in 107 days for medium severity vulnerabilities. (Note: In our State of Software Security Research, we talk about fixing 50 percent of flaws – or half-life – because this metric illustrates how effective teams are in remediating vulnerabilities.) This contradicts the Log4j data above, which shows that remediation is not happening quickly for this open-source library, especially for Log4j 1.2.x. 

The research also found several exogenous factors slowing developers down. Developers rarely lack the skills to fix things, but it boils down to a lack of information and/or lack of resources (e.g. developers’ time and/or staff). Specifically, when developers don’t have the resources to fix vulnerabilities, it can take nearly 13.7 times longer to fix half of them. In addition, developers who lack contextual information about how a vulnerable library relates to their application take 7+ months to fix 50 percent of their vulnerability backlog. 

Why the Need for Change is Now 

Log4j is just one example of how vulnerabilities in open source pose significant risks that can impact operations, data security, and overall IT health. Strategic technology choices can make a big impact on how much risk your open source is exposing you to. New SEC regulations make it clear that we all play our part in security. The National Cybersecurity Strategy declared that the “security and resiliency of open-source software is a national security, economic and a technology innovation imperative.” 

At the time Log4Shell emerged, our 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 data in this post shows how well-informed this statement is. To make the change that is needed here are top tips to reduce open-source-based security technical debt. 

• Know what's going into the applications you build. With SCA and Infrastructure as Code scanning, you can make a constrained subset of allowable modules developers can use. Ensure there are policies to disallow or set grace periods around open-source vulnerabilities by severity and/or “breaking the build” such that developers aren’t allowed to deploy changes that introduce new vulnerabilities (in first or third-party code). Make sure you optimize for risk with a solution that can identify the vulnerable methods that really matter.  

• Know what’s in the software you've purchased or acquired (perhaps through an M&A event). Ask for an SBOM for third-party software you install. It's likely that at some point the software you make or the software you use will contain a vulnerability derived from an open-source component. Being able to quickly identify and remediate it might keep you out of serious trouble.