Even after concerted efforts to address the infamous Log4Shell vulnerability, more than one-third (38%) of applications continue to operate on vulnerable versions of Log4j, a widely-used open-source logging library, indicates recent research from Veracode.
Tracked as CVE-2021-44228 aka Log4Shell, the vulnerability affects Log4j versions Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) and could be used for remote code execution. Since its public disclosure, multiple hacker groups, including state-sponsored ones, have been exploiting the flaw to compromise targets. Most recently, the North Korean hacking group Lazarus has been using the bug to deploy three novel malware families.
Veracode analyzed data from software scans 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. The company found that 2.8% of apps are still utilizing Log4j versions susceptible to the Log4Shell vulnerabilities (Log4j2 2.0-beta9 through 2.15.0) and 3.8% of apps use Log4j2 2.17.0, a version patched against Log4Shell but harboring CVE-2021-44832, a high-severity remote code execution (RCE) vulnerability.
32% of applications run on Log4j2 1.2.x, an end-of-life version since August 2015. This obsolete version has accumulated seven critical vulnerabilities, with the latest three, CVE-2022-23307, CVE-2022-23305, and CVE-2022-23302, disclosed in January 2022.
The study also draws attention to the broader issue of infrequent updates to third-party libraries in software development. According to the State of Software Security (SOSS) v11 Open Source Edition research, developers fail to update third-party libraries 79% of the time after including them in a code base. This tendency contributes to the prevalence of applications running end-of-life versions like Log4j2 1.2.x.
While the research indicates that developers can promptly fix vulnerabilities when alerted through scans (50% of vulnerabilities are fixed in 89 days overall, in 65 days for high-severity vulnerabilities and in 107 days for medium-severity vulnerabilities), the Log4j data contradicts this trend, especially for Log4j 1.2.x.
“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, the researchers noted. 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.”