log4j-core until version 2.15.0 has a major security leak that can be exploited by sending prepared strings that are logged with log4j. Potential candidates would be headers or often also simple form fields that are sent to java backends.
The CVE can be found here. With a score of 10/10 this should be addressed as soon as possible.
The spring blog says that a fix has been made in version 2.15.0 which is available since December 10th – the same day as the issue received big publicity.
Apache posted an article to announce 2.16.0 on December 13th.
Update: Debian security mailing list just announced this:
It was found that the fix to address CVE-2021-44228 in Apache Log4j, a Logging
Framework for Java, was incomplete in certain non-default configurations. This
could allow attackers with control over Thread Context Map (MDC) input data
when the logging configuration uses a non-default Pattern Layout with either a
Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern
(%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern
resulting in a denial of service (DOS) attack.
For the oldstable distribution (buster), this problem has been fixed
in version 2.16.0-1~deb10u1.
For the stable distribution (bullseye), this problem has been fixed in
version 2.16.0-1~deb11u1.
We recommend that you upgrade your apache-log4j2 packages.
So please make sure to update to 2.16.0 instead of 2.15.0.
Important Update
The log4j team already released 2.17.0 which is available for download. It fixes CVE-2021-45105.
Package : apache-log4j2
CVE ID : CVE-2021-45105
Debian Bug : 1001891
It was found that Apache Log4j2, a Logging Framework for Java, did not protect
from uncontrolled recursion from self-referential lookups. When the logging
configuration uses a non-default Pattern Layout with a Context Lookup (for
example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC)
input data can craft malicious input data that contains a recursive lookup,
resulting in a denial of service.
For the oldstable distribution (buster), this problem has been fixed
in version 2.17.0-1~deb10u1.
For the stable distribution (bullseye), this problem has been fixed in
version 2.17.0-1~deb11u1.
Update, 29.12.2021
Log4j has relased another version fixing CVE-2021-44832:
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.New version has already been release to public maven repos: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
Spring Boot
Taken from an announcement on the Spring blog Spring Boot with its logback logger isn’t affected if you didn’t switch to log4j on purpose.
Also logback has just closed a CVE (https://nvd.nist.gov/vuln/detail/CVE-2021-42550). But here the attacker needs write access to the logging config. Here the jira issue for it: https://jira.qos.ch/browse/LOGBACK-1591. An update has also been added to https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot.
Spring Boot 2.6.2 has updated to 2.17.0 and doesn’t include 2.17.1 yet.
Android
Android is using its own log system and switching to log4j is a quite tricky task from what I’ve read so far. So the default logger in Android applications isn’t affected by log4shell as well.
JEE – Wildfly
Wildfly is using jboss-logging package and never relied on log4j. So wildfly users are also not affected as long as you don’t ship the artifact yourself. For further details read the article on wildfly news.
Other Applications
log4j is very widely spread in the java open source community and the chance that it is deeply knit into your applications is very high.
Typical javascript applications or flutter apps aren’t based on Java and therefor shouldn’t be affected themselves. But their backends could be!
SLF4j
“The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time.” [http://www.slf4j.org/]
So the question if your application that is using slf4j is vulnerable can’t be answered so easily because it depends on the implementation you chose behind the scenes. Typical libs you can find in applications that are using log4j as their logging implementation behind the slf4j facade are log4j-core, log4j-slf4j-impl, log4j-over-slf4j, slf4j-log4j12, … Also the existence of a log4j.properties or log4j.xml file in the root of your classpath is a very good hint that the app is using log4j.
Of course I don’t take over any responsibility that the information on this page is correct or that your app is safe. Please review yourself and check your apps.