Log4j 2nd Year Anniversary Still a Pain

Recent research reports reveal that even after two years, several organizations are still vulnerable to Log4j.

The analysis is done between August 15 and November 38,278, covering unique applications running Log4j versions 1.1 to 3.0.0-alpha1 across 3866 organizations and found that 38% are still using vulnerable versions of Log4j. The majority (32%) of these are running Log4j2 1.2.x, which contains three critical flaws: CVE-2022-23307, CVE-2022-23305, and CVE-2022-23302.

A further 3.8% are running Log4j2 2.17.0, which contains CVE-2021-44832. Just 2.8% are still on versions exposed to the Log4Shell vulnerabilities: Log4j2 2.0-beta9 to 2.15.0.

The original Log4Shell vulnerability (CVE-2021-44228) was first discovered in November 2021 and immediately hit the headlines because the Apache logging system it’s found in is used in a huge range of applications.

The RCE flaw relatively easy for threat actors to exploit, as long as they could force a vulnerable application to log a particular string of characters. The EOL versions of Log4j are also vulnerable to three additional critical bugs announced by Apache, bringing the total to seven high and critical-rated issues.

Earlier this year, new research revealed that Log4Shell had been used as an initial infection vector in 31% of compromises.

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 one in three 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.”

Though most organizations patched to secure versions within weeks rather than dealing with exploits, often the biggest pain felt was the patching process itself, which could have involved hundreds of apps, depending on the organization.

This research was documented by Veracode.