2 min

Tags in this article

, ,

About just over a third of enterprise applications that rely on Log4j libraries are still using a version vulnerable to Log4Shell.

That’s according to figures from Veracode. Many companies still have not addressed the Log4j vulnerability in their applications, which has been known for two years, despite frequent calls to fix it and the availability of solutions.

The vulnerabilities are active mainly because applications are using an outdated, unpatched version of Log4j. These are versions 1.1 through 3.0.0-alpha1.

Versions Log4j 2.0-beta9 through 2.15.0 are especially vulnerable, as they are directly susceptible to the infamous Log4Shell vulnerability or CVE-2021-44228. This has the maximum vulnerability rating and was discovered back in December 2021. At the time of discovery, this zero-day vulnerability was already extremely frequently exploited by hackers.

Many vulnerable versions are in use

Veracode found that companies still haven’t addressed these highly vulnerable versions two years later. About 2.8 per cent of all applications surveyed use the Log4j variants 2.0-beta9 through 2.15.0.

In addition, 3.8 per cent are still using the Log4j 2.17.0 version, which is susceptible to another severe vulnerability. Furthermore, 32 per cent of the applications surveyed still use Log4j version 1.2.x, the support of which has been discontinued since August 2015. For these latest versions, several critical vulnerabilities were uncovered last year.

Patch processes take a very long time

What is possibly even more worrying, Veracode further concludes, is that developers very often, in 79 per cent of the cases surveyed, do not update third-party libraries when they insert them into their code. This is because they want to prevent the functionality from causing problems.

Furthermore, 50 per cent of development projects take about 65 days before security issues with high vulnerabilities are addressed. It also takes 13.7 times longer and more than seven months to fix about half of the issues in the backlog due to lack of staff.

Also read: Log4Shell in 2023: big impact still reverberates