The Apache Software Foundation project Apache Logging Services has responded to a security vulnerability that is described in two CVEs, CVE-2021-44228 and CVE-2021-45046. In this post we’ll list the CVEs affecting Log4j and keep a list of frequently asked questions. 

The most recent CVE has been addressed in Apache Log4j 2.16.0, released on 13 December. We recommend that users update to 2.16.0 if possible. While the 2.15.0 release addressed the most severe vulnerability, the fix in Log4j 2.15.0 was incomplete in some non-default configurations and could allow an attacker to execute a denial of service (DoS) attack. Users still on Java 7 should upgrade to the Log4j 2.12.2 release. 

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints

In Apache Log4j2 versions up to and including 2.14.1, the JNDI features used in configurations, 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.

See the entire description and history on the Apache Logging security page.

CVE-2021-45046: Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. 

This could allow attackers, in some situations, to craft malicious input data using a JNDI Lookup pattern resulting in a DoS attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.

See the entire description and history on the Apache Logging security page.

CVE-2021-4104: Deserialization of untrusted data in JMSAppender in Apache Log4j 1.2

Apache Log4j 1.x has been end-of-life since August 2015. However, we are aware that it is still a dependency for some applications and in use in some environments. We have found that Log4j 1.2, if used in a non-default configuration with JMSAppender used to perform JNDI requests, is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration.

This is not the same vulnerability described in the recent Log4j 2.x CVEs, but it could also result in remote code execution (RCE), so we are providing this information to make users aware of the vulnerability and urge them to upgrade to Log4j 2.16.0 or 2.12.2, or to take steps to mitigate the issue by disabling the use of JMSAppender to perform JNDI requests.

Frequently Asked Questions about the Log4j vulnerabilities

In this section we’ll try to address some of the most common questions that our community and press have had about the Log4j vulnerabilities. 

What about systems or applications with Log4j 1.x?

While the Log4j 1.x series is not known to be affected by the two CVEs above, it has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

How many systems have been impacted or how widespread is the impact of this CVE?

Log4j, like all software distributed by the Apache Software Foundation, is open source. It’s been distributed via a mirror system for many years and then more recently via a Content Delivery Network (CDN) directly to users and developers, and also to organizations who have then shipped it as part of their projects, products or services. 

We know that Log4j is included in a number of ASF projects, other open source projects and a number of products and services. But beyond that any numbers would merely be speculation and most likely wrong by a wide margin.

Are any other Apache projects impacted by the Log4j vulnerabilities?

Yes. The Apache Security Team has compiled a list of projects that are known to be affected with links to updates if available. See the Apache projects affected by log4j CVE-2021-44228 blog post.

Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

How can I get help?

If you need help on building or configuring Log4j or other help on following the instructions to mitigate the known vulnerabilities listed here, please send your questions to the public Log4j Users mailing list

If you have encountered an unlisted security vulnerability or other unexpected behavior that has security impact, or if the descriptions here are incomplete, please report them privately to the Log4j Security Team. Thank you.