Roughly 38% of applications using the Apache Log4j library are using a version vulnerable to security issues, including Log4Shell, a critical vulnerability identified as CVE-2021-44228 that carries the maximum severity rating, despite patches being available for more than two years.
Log4Shell is an unauthenticated remote code execution flaw that allows taking complete control over systems with Log4j 2.0-beta9 and up to 2.15.0.
The circumstance prompted an extensive campaign to notify affected project maintainers and system administrators, but despite numerous warnings, a significant number of organizations continued to use vulnerable versions long after patches became available.
Two years after the vulnerability was disclosed and fixes were released, there are plenty of targets still vulnerable to Log4Shell.
A report from application security company Veracode, based on data collected between August 15 and November 15, highlights that old problems can persist for an extensive periods.
Veracode gathered data for 90 days from 3,866 organizations that use 38,278 applications relying on Log4j with versions between 1.1 and 3.0.0-alpha1.
Of those apps, 2.8% use Log4J variants 2.0-beta9 through 2.15.0, which are directly vulnerable to Log4Shell.
Another 3.8% use Log4j 2.17.0, which, although not vulnerable to Log4Shell, is susceptible to CVE-2021-44832, a remote code execution flaw that was fixed in version 2.17.1 of the framework.
Finally, 32% are using Log4j version 1.2.x, which has reached the end of support since August 2015.
Those versions are vulnerable to multiple severe vulnerabilities published until 2022, including CVE-2022-23307, CVE-2022-23305, and CVE-2022-23302.
In total, Veracode found that about 38% of the apps within its visibility use an insecure Log4j version.
This is close to what software supply chain management experts at Sonatype report on their Log4j dashboard, where 25% of the library's downloads in the past week concern vulnerable versions.
The continual use of outdated library versions indicates an ongoing problem, which Veracode attributes to developers wanting to avoid unnecessary complications.
According to Veracode's findings, 79% of developers opt never to update third-party libraries after their initial inclusion in their code base to avoid breaking functionality.
The study showed that it takes 50% of projects over 65 days to address high-severity flaws.
Veracode's data shows that Log4Shell has not been the wake-up call many in the security industry hoped it would be.
Instead, Log4j alone continues to be a source of risk in 1 out of 3 cases and may very easily be one of the multiple ways attackers can leverage to compromise a given target.
The recommendation for companies is to scan their environment, find the versions of open-source libraries in use, and then develop an emergency upgrade plan for all of them.
Atlassian patches critical RCE flaws across multiple products.
December Android updates fix critical zero-click RCE flaw.
This Cyber News was published on www.bleepingcomputer.com. Publication date: Sun, 10 Dec 2023 15:45:16 +0000