Update: December 13, 2021
As an update to CVE-2021-44228, the fix in version 2.15.0 was incomplete on some non-default configurations. Additional issue identified and tracked CVE-2021-45046. For a more comprehensive fix for this vulnerability, it is recommended to update to Log4j2 2.16.0.
The original post below has now been updated:
December 15, 2021, 12:49 PM PT
We know that many of you are working hard to fix the new and dangerous Log4j 2 vulnerability CVE-2021-44228, which has a score of 10.0 CVSS. We are sending #hugops and best wishes to all of you who are working on this vulnerability, now in the name of Log4Shell. This vulnerability in Log4j 2, a very popular Java logging library, allows remote code execution, often from a context readily available to an attacker. For example, it was found in Minecraft servers that allowed commands to be written into chat logs where they were then sent to the logger. This makes it a very dangerous vulnerability, as the registry library is widely used and could be easy to exploit. Many open source software maintainers work hard to fix and update the software ecosystem.
We want to help you as much as we can through this challenging time, and we’ve gathered as much information for you here as possible, including how to spot CVE and potential mitigations.
We will update this post as more information becomes available.
Am I weak?
The vulnerable versions of Log4j 2 are versions 2.0 through 2.14.1 inclusive. The first stable release is 2.15.0. The fix in 2.15.0 was incomplete and 2.16.0 is now the recommended version to upgrade to. We highly encourage you to update to the latest version if you can. If you are using a version prior to 2.0, you are also not at risk.
You may not be vulnerable to attack if you are using these versions, because your configuration may already mitigate this (see Mitigation section below), or the things you log may not include any user input. It can be hard to validate this without understanding in detail all the code paths you might log in, and where you can get input from. So you will probably want to upgrade all code with vulnerable versions.
docker scan The command previously shipped in Docker Desktop 4.3.0 and earlier versions unfortunately does not capture this vulnerability in scans. Please update to Docker Desktop 4.3.1+ with
docker scan 0.11.0+, which we released today December 11, 2021.
If you are using files
docker scan From Linux, you can download the binaries from GitHub and install them in the extensions directory as described in the instructions here. We will soon update the Linux CLI version to include the updated Docker check.
If you are using the updated version, you will see a message in the output log like this:
Upgrade org.apache.logging.log4j:firstname.lastname@example.org to org.apache.logging.log4j:email@example.com to fix ✗ Arbitrary Code Execution (new) [Critical Severity][https://snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2314720] in org.apache.logging.log4j:firstname.lastname@example.org introduced by org.apache.logging.log4j:email@example.com
To test this, you can check a weak image, for example this image contains a weak copy.
docker scan elastic/logstash:7.13.3
Or cut all other weak points
docker scan elastic/logstash:7.13.3 | grep 'Arbitrary Code Execution'
For more information about docker inspection, see the documentation.
Docker Hub checks
updated: Docker Hub security checks After 1700 UTC, December 13, 2021, they now correctly identify the Log4j2 vulnerability. Scans before this date do not currently reflect this vulnerability. We are looking into how to address this and will update this post when we do. Please use
docker scan From the above updated version of images pushed before 1700 UTC Dec 13, 2021.
You may want to use a Web Application Firewall (WAF) as an initial part of the mitigation and repair process.
This issue can be mitigated in previous versions of Log4j 2 (<2.16.0) by removing the JndiLookup class from the classpath.
zip -q -d log4j-core-*.jarorg/apache/logging/log4j/core/lookup/JndiLookup.class
Official Docker Images
A number of Docker Official images contain vulnerable versions of Log4j 2. For information on current state updates of official Docker images, please see https://docs.docker.com/security/.
Other images on Docker Hub
We work with authorized Docker publishers to identify and update their affected images. We are looking for ways to show you the affected photos and will continue to update this post as we have more information.
Is Docker infrastructure affected?
Docker Desktop and Docker Hub are not affected by the log4j 2 vulnerability. Docker largely uses Go code to build our apps, not Java. Although we use some Java applications internally, we have confirmed that we are not vulnerable to CVE-2021-44228 and CVE-2021-45046.