Aqua Blog

CVE-2021-45046: Second Log4j Security Vulnerability Discovered

CVE-2021-45046: Second Log4j Security Vulnerability Discovered

Dec 17 update: The CVSSv3 score for CVE-2021-45046 has been raised from 3.7 to 9.0.

While many organizations are still dealing with the discovery and mitigation process for the previous Log4j CVE, the project has announced that another vulnerability CVE-2021-45046 has been discovered due to an incomplete fix in Log4j 2.15.0. In response, a new version of Log4j (2.16.0) has been released that by default disables JNDI functionality, which was the source of the original issue.

Incomplete mitigations leave risks

Since the original vulnerability was released, there has been a panoply of suggested mitigations for use when patching is not an immediate option. Inevitably, when these mitigations are developed quickly, subsequent research has revealed that they may not be as solid as first thought.

Particularly relevant for this new CVE are mitigations that initially appeared to remediate the issue, setting formatMsgNoLookups=true when invoking Java or setting LOG4J_FORMAT_MSG_NO_LOOKUPS=true as an environment variable.

Recent research has concluded that even with these mitigations in place, older versions of Log4j may be vulnerable to remote code execution.

The additional risk noted in CVE-2021-45046 is a denial-of-service attack that can occur when Log4j 2.15.0 is in use. This is generally considered less serious than a remote code execution, however, the safest path for companies will still be to ensure that they fully upgrade to the latest Log4j version.

How Aqua can help

The detection and mitigation capabilities published for the original Log4j issues also apply to show and mitigate where Log4j 2.15.0 is an issue.

CVE-2021-45046 Vulnerability Detection

Using Trivy to detect vulnerable software libraries

Aqua’s open source scanning tool Trivy can detect and report on both the original Log4j issue (CVE-2021-44228) and this new one. Scanning a container image with a known vulnerable Log4j version will produce output like this:

trivy scan results for log4j-core


The Log4j vulnerability has become one of the largest security issues we’ve seen in recent times. With the level of attention now being focused on this problem both by attackers and defenders, it’s likely that we’ll see further information and possible vulnerabilities.

In the aftermath of the immediate response, companies should carefully consider how they can manage this type of risk strategically. Improving detection of software versions and using software supply chain security tools are good examples of defense-in-depth security measures that can provide short-term mitigations. Using these tools gives IT departments the time needed to coordinate comprehensive patching and testing of their software systems in a safe and controlled fashion.


Rory McCune
Rory was a Cloud Native Security Advocate at Aqua. He has worked in the Information and IT Security arena for the last 20 years in a variety of roles. He is an active member of the container security community having delivered presentations at a variety of IT and Information security conferences. He has also presented at major containerization conferences and is an author of the CIS Benchmarks for Docker and Kubernetes and main author of the Mastering Container Security training course which has been delivered at numerous industry conferences including Blackhat USA.