Revision history

13.12.2021Initial CVE - CVE-2021-44228
15.12.2021Second CVE - CVE-2021-45046

The log4j vulnerabilities

On December 14. a new attack vector was found, CVE-2021-45046, that invalidated some of the mitigations used for the initial vulnerability CVE-2021-44228 in some non-default configurations.

This means that only two real mitigations are available, which are an upgrade to the most recent version of log4j or complete removal of the JndiLookup class from classpaths.

On December 9, 2021 a serious vulnerability, CVE-2021-44228, in one of the most widely used Java logging libraries Log4j was disclosed. and it affect versions 2 of Log4j from 2.0 and 2.14.1. An older, end-of-life, version 1 of the library is not affected by this vulnerability but should be phased out none the less.

“An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.” according to the Apache Log4j security announcement.

  • The base CVSS Score is 10.0
    • CVSS: 3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • The library has been patched as of 2.16.0
  • LDAP/LDAPS/RMI and DNS prefixes have all been observed in the wild.


One of the greatest challenges posed by this vulnerability is that it’s difficult to figure out which servers are affected. Although everyone should first consider internet-facing systems in Java, determining both the breadth and depth is quite tricky and CVE-2021-44228 is not restricted to only internet facing Java services. The vulnerability may be found anywhere where user-supplied data is processed and logs are maintained.

Potential Impact

Malicious attackers may

  • Plant backdoors to sell or use later.
  • Steal data
  • Ransomware
  • Cause “Chaos” or destroy

How to mitigate CVE-2021-44228

Previous recommendations

As the threat landscape is rapidly evolving several mitigation strategies have been proposed that have later been deemed insufficient due new attack vectors.

The following recommendations can therefore not be considered sufficient at this time

  • Initially an upgrade to Log4j 2.15.0 was recommended but due to the new attack vector it is no longer considered sufficient.
  • If you are unable to upgrade, then in releases >= 2.10 this behavior can be mitigated by setting either the system:
  • This prevents {$jndi:…} activity from triggering network connection which may mitigate exfiltration and code implants

Current recommendations

The industry standard mitigations, as of December 15th, are the following.

  • Upgrade to Log4j 2.16.0 if possible
  • For all releases of log4j2, the mitigation is to remove the JndiLookup class from the classpath: Remove the JNDILookup class from classpath.
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Less effective mitigations

In rare cases when neither is possible, it may be possible to mitigate or slightly reduce potential impact by performing any of the following:

  • Prevent outbound connections from servers and remove the possibility of fetching LDAP and RMI payloads over the internet.
  • Certain WAF’s have already published rules to prevent this exploit, such as CloudFlare.
  • It is also possible to update Java, which will mitigate LDAP class loading but not RMI
  • With all that said and done, it’s always possible that a malicious attacker may plant a Gadget that may still work in your specific environment.


Reading Material