CVE-2021-44228: Critical Apache Log4j vulnerability


Apache Log4j2 <=2.14.1 JNDI features used in the configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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. In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true”
or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see
protects against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.


A critical remote code execution vulnerability in the popular Apache Foundation Log4j library has been disclosed. It could allow an attacker to completely take control of an affected server.
It can be leveraged in default configurations by an unauthenticated remote attacker to target applications that make use of the Log4j library. This vulnerability,
tracked as CVE-2021-44228, received a CVSS severity score of a maximum 10.0, and is widely believed to be easy to exploit.
Apache Foundation Log4j is a logging library designed to replace the built-in log4j package. It is often used in popular Java projects, such as Apache Struts 2 and Apache Solr.

Apache has released an updated version, Log4j 2.15.0.

In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment
variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class
from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
For more information please visit

Reference URL’s: