Log4j vulnerability threatens 35,000 Java packages

Log4j threatens Java packages

Google scanned Maven Central, the largest Java repository to date, and found that the Log4j vulnerability threatened 35,863 Java packages.

The packages are vulnerable to either the original Log4Shell exploit (CVE-2021-44228) or the second RCE problem discovered after the patch was released (CVE-2021-45046).

The vulnerabilities could allow an attacker to execute remote code execution using the insecure JNDI lookup function provided by the log4j log library. This vulnerable feature was enabled by default in many versions of the library.Google experts write.

This vulnerability has gripped the information security ecosystem since its disclosure on December 10 due to its severity and widespread impact. As a popular logging tool, log4j is used by tens of thousands of software packages (known as artifacts in the Java ecosystem) and projects in the software industry.

Researchers note that usually after the discovery of the next vulnerability, it turns out that it affects only about 2% of the content of Maven Central. However, the 35,000 packages vulnerable to Log4Shell is roughly 8% of all Maven Central content, and experts point out that the percentage is “huge.”

Currently, 4620 developers out of 35,863 packages (13% of the total number of vulnerable packages) have already updated their products. For comparison, the researchers cite similar statistics for past Java vulnerabilities, when about 48% of libraries received patches.

This statistic is greater than any other statistic, which reflects the tremendous efforts of open source software developers, cybersecurity teams and consumers around the world. analysts say.

Alas, experts write that the Log4Shell problem is unlikely to be completely fixed in the coming years. The main difficulty is that Log4j is not always a direct dependency and is often a dependency on another dependency. In such situations, developers of vulnerable packages have to wait for other developers to update their applications, which in some cases can take weeks or even months.

For example, according to statistics collected by Google, Log4j is a direct dependency only for 7000 out of 35000 packages, which means that many developers will most likely have to disable indirect dependencies that have not been updated to use safe alternatives.

Log4j threatens Java packages

Let me remind you that we also reported that Experts are already fixing attacks on the Log4Shell vulnerability.

By Vladimir Krasnogolovy

Vladimir is a technical specialist who loves giving qualified advices and tips on GridinSoft's products. He's available 24/7 to assist you in any question regarding internet security.

Leave a comment

Your email address will not be published. Required fields are marked *