​​Since December 10, in a span of just 20 days, there have been four different vulnerabilities published against Log4j. Engineers who worked long hours to update their Log4j versions to 2.15.0 on December 11th, were told three days later that they needed to do it all over again and upgrade to version 2.16.0. This is not sustainable. And yet the risks are high. Looking backward, we see that Log4j has been vulnerable since 2013 to the kinds of attacks described in CVE-2021-44228.

Another — though unlikely — vulnerability was discovered in Log4j’s latest versions: CVE-2021-44832. This is an Arbitrary Code Execution exploit using, yet again, the now infamous JNDI functionality. The vulnerability lets an attacker with control over the Log4j configuration set a malicious datasource for the JDBC (Java DataBase Connectivity API) appender. The datasource refers to an attacker-controlled JNDI URI that will execute arbitrary code on the application using Log4j.

The announcement of Log4j vulnerability cve-2021-44228 sent security and development teams into a tailspin and highlights the one of biggest challenges of open source security: dependency management. The open source libraries that make up up to 80% of our applications are often a tangled web of dependencies.

The notorious Log4Shell vulnerability CVE-2021-45046, has put Log4j in the spotlight, and grabbed the entire Java community’s attention over the last couple of weeks. Maintainers of Java projects that use Log4j have most probably addressed the issue. Meanwhile, non-java developers are enjoying relative peace of mind, knowing that they are unaffected by one of the major vulnerabilities found in recent years. Unfortunately, this is an incorrect assumption.

A third Log4j2 vulnerability was disclosed the night between Dec 17 and 18 by the Apache security team, and was given the ID of CVE-2021-45105. According to the security advisory, 2.16.0, which fixed the two previous vulnerabilities, is susceptible to a DoS attack caused by a Stack-Overflow in Context Lookups in the configuration file’s layout patterns. What is this CVE about? What can you do to fix it? How does it differ from the previous CVEs?

As security and development teams rushed to assess the now-notorious Log4Shell vulnerability published December 10 (CVE-2021-44228), another, more minor vulnerability was discovered in Log4j — CVE-2021-45046. To understand the newly-discovered vulnerability, it is important to get the full picture and background on the original Log4j issue.

A newly published critical vulnerability in Apache’s widely popular Log4j Java library, CVE-2021-44228 (CVSS score 10) was published over the weekend, causing a lot of concern.