# Subject: Apache Log4j2 Vulnerability - CVE-2021-44228, CVE-2021-45046, CVE-2021-45105, CVE-2021-44832 - ESA-2021-31 **Note - We will update this announcement with new details as they emerge from our analysis. Please check back periodically.** ## Update Log * Dec 16, 2021 - 04:20 UTC - Update Summary: ECK 1.9 released which automatically adds the JVM option to impacted Elasticsearch clusters managed by ECK. * Dec 17, 2021 - 23:50 UTC - Update latest release of APM Java Agent to 1.28.2. Statement of plan to release 7.16.2 and 6.8.22. Added mitigation summary matrices for APM Java Agent, Elasticsearch, Logstash, and Elasticsearch on Elastic Cloud. * Dec 18, 2021 - 23:40 UTC - Added statement that Elasticsearch, Logstash, and APM Java agent have no known vulnerabilities to CVE-2021-45105. Targeting Dec 19 for release of Elasticsearch and Logstash 7.16.2 and 6.8.22 * Dec 19, 2021 - 13:32 UTC - Elastiscsearch and Logstash 7.16.2 and 6.8.22 are now released. These releases include the most recent version of Log4j (2.17.0). * Dec 20, 2021 - 19:55 UTC - APM Java Agent has no known vulnerabilities to CVE-2021-45105. Regardless, we do intend to remain current on log4j and plan to update the APM Java Agent after log4j 2.12.3 becomes available. * Dec 22, 2021 - 20:30 UTC - APM Java Agent updates available with log4j 2.12.3 * Jan 6, 2022 - 01:20 UTC - Update with responses for CVE-2021-44832. APM Java Agents 1.26.2 and 1.28.4 release. ECE 2.12.4 release. Planned release for Elasticsearch, Logstash 7.16.3 and 6.8.23 * Jan 11, 2022 03:40 UTC - Update APM Java Agents advisory for CVE-2021-44832. * Jan 13, 2022 21:00 UTC - Elasticsearch, Logstash 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1. Note about ECE and Apache Zookeeper. ## Summary A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1. This announcement summarizes the currently known potential impacts to Elastic products and related announcements for mitigations of the issue. Elastic engineering and security teams continue to actively work on the analysis and any actions our users should perform, alongside detection signatures that may be used to identify exploitation of the vulnerability. ### [Update Jan 13] Elasticsearch, Logstash 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1. By default, Elasticsearch and Logstash have no known vulnerabilities to CVE-2021-44832. ### [Update Jan 11] APM Java Agents versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 are susceptible to CVE-2021-44832 when used in an application where an attacker has access to create files within the application directory. Users should upgrade to APM Java Agent versions 1.26.2 or 1.28.4, which have Log4j 2.12.4 which addresses CVE-2021-44832. ### [Update Jan 6] A vulnerability (CVE-2021-44832) was disclosed on December 28th where an attacker having access and permission to write the Log4j configuration file can result in Remote Code Execution. By default, Elasticsearch and Logstash have no known vulnerabilities to this as relevant configuration files are only writable by cluster administrators. We will release 7.16.3 and 6.8.23 to update Log4j to 2.17.1, targeting Jan 13. ~~APM Java Agents have no known vulnerabilities for CVE-2021-44832.~~ **See Jan 11 Updates** , versions 1.27.0, 1.27.1, 1.28.0 and 1.28.1 are susceptible to CVE-2021-44832 when an attacker has access to create files within the application directory. APM Java Agent versions 1.26.2 and 1.28.4 are available with updated Log4j 2.12.4. ECE has no known vulnerabilities for CVE-2021-44832. ECE 2.12.4 is available which updates internal ECE components to Log4j 2.17.1 ### [Update Dec 19] Elastiscsearch and 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not trigger false positives in vulnerability scanners. ### [Update Dec 18] Log4j2 Version 2.17.0 was released to address a denial of service vulnerability reported in CVE-2021-45105. Elasticsearch, Logstash, and APM Java agent are not exploitable by this vulnerability and the prior guidance is still valid. As previously announced, we are targeting to release Elasticsearch and Logstash 7.16.2 and 6.8.22 which will include the latest version of Log4j (2.17.0). The target for this release is December 19. ### [Update Dec 17] The 7.16.1 and 6.8.21 releases of Elasticsearch and Logstash fully mitigate CVE-2021-44228 and CVE-2021-45046, but may trigger false positives in vulnerability scanners based on the bundled version of Log4j. In order to address these false positives, we will release 7.16.2 and 6.8.22 containing an updated version of Log4j that should not trigger false positive alerts from vulnerability scanners. Several new Log4j versions have been released in recent days, and we are waiting for some stability before incorporating the latest Log4j and releasing these new versions. ### [Update Dec 15] A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch, APM Java Agent, and Logstash are unchanged by this new vulnerability. ### Elasticsearch Supported versions of Elasticsearch (6.8.9+, 7.8+) used with recent versions of the JDK (JDK9+) are not susceptible to either remote code execution or information leakage. This is due to Elasticsearch’s usage of the Java Security Manager. Most other versions (5.6.11+, 6.4.0+ and 7.0.0+) can be protected via a simple JVM property change. The information leak vulnerability does not permit access to data within the Elasticsearch cluster. We have released Elasticsearch 7.16.1 and 6.8.21 which contain the JVM property by default and remove certain components of Log4j out of an abundance of caution. This is applicable to both CVE-2021-44228 and CVE-2021-45046. Elasticsearch has no known vulnerabilities to CVE-2021-45105. Elasticsearch 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1 _**Details below.**_ ### Elastic Cloud Our security testing has not identified any exploitable RCEs against any Elastic Cloud products. As a normal practice we will update components with the latest version of Log4j as they become available. We recommend that users who are on versions before 7.2 restart their deployments to pick up an updated setting. _**Details below.**_ ### APM Java Agent _**Details below**_ ### Elastic Cloud Enterprise Our security testing has not identified any exploitable vulnerabilities related to this issue. We are continuing to analyse the issue and will advise with any updates. As a normal practice we will update any components which include the vulnerable Log4j versions in the next release. _Mitigation details for an Elasticsearch cluster managed by ECE are below._ #### [Update Jan 13] ECE uses Apache Zookeeper which depends on log4j 1.2.17 as an internal dependency. There is no known exploitation of CVE-2021-4104 in this implementation, and there are currently no upstream plans announced by the Apache Zookeeper project to update the log4j version in Zookeeper. #### [Update Jan 6] ECE has no known vulnerabilities for CVE-2021-44832. ECE 2.12.4 is available which updates internal ECE components to Log4j 2.17.1. To remove impacted Log4j assemblies from the filesystem, ECE customers will need to: 1. Upgrade their installation to 2.12.4 or newer. This will update all ECE components as well as ECE system clusters to use components that have been updated to Log4j 2.17.0 or newer. 2. Upgrade all deployments within the installation to use versions 7.16.2 / 6.8.22 or newer for major versions 7 / 6 respectively. 3. Remove stack packs for impacted deployment stack versions. Removing stack packs for versions prior to 7.16.2 / 6.8.22 will ensure new deployments violating scan policies won’t get created in the future. 4. Purge all old images from the filesystem. Customers can run `docker image prune -a` on all ECE hosts to remove all images not currently in use by running containers. ### Elastic Cloud on Kubernetes While the ECK Operator is not impacted by this vulnerability, _mitigation details for an Elasticsearch cluster managed by ECK are below._ ### Logstash Exposure to remote code execution exists on JDKs prior to 8u191. On newer versions of JDKs there is exposure to Denial of Service and information leakage, but no known remote code execution exposure. Logstash has no known vulnerabilities to CVE-2021-45105. Logstash 7.16.3 and 6.8.23 are released, which upgrade log4j to 2.17.1 _**Details below.**_ ### Swiftype Our security testing has not identified any exploitable RCEs against Swiftype products. Our investigation continues and we will provide updates of any new findings. We have mitigations in place as a precaution and will update components with the latest version of Log4j as they become available. ### Not Impacted We have validated that the vulnerability does not exist in the following Elastic products: * APM Server * Beats * Cmd * Elastic Agent * Elastic Cloud on Kubernetes * Elastic Endgame * Elastic Maps Service * Endpoint Security * Enterprise Search * Fleet Server * Kibana * Machine Learning * * * ## APM Java Agent announcement (ESA-2021-31) In versions 1.17.0-1.28.0, the only known way the CVE-2021-44228 vulnerability may be exploited is when the APM Java Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format (log_format_stdout/log_format_file=PLAIN_TEXT). Additionally CVE-2021-44832 may be exploited in versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 in the circumstance where an attacker has access to create files within your application directory. **Affected Versions:** Versions 1.17.0-1.28.1, excluding 1.26.1 & 1.26.2 **Solutions and Mitigations:** Users running affected versions should upgrade to the latest version (1.26.1, 1.26.2 or 1.28.3 or newer). In versions 1.17.0-1.28.0, CVE-2021-44228 can be mitigated manually by setting system property -Dlog4j2.formatMsgNoLookups=true. In versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1, CVE-2021-44832 can be mitigated by ensuring filesystem permissions prevent unauthorized users writing the log4j.properties file in the application directory. ### [Update Jan 11] CVE-2021-44832 may be exploited in versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 if an attacker has access to create files within your application directory. Users should upgrade to APM Java Agent versions 1.26.2 or 1.28.4, which have Log4j 2.12.4 which addresses CVE-2021-44832. ### [Update Jan 6] APM Java Agent versions 1.26.2 and 1.28.4 are available with updated Log4j 2.12.4. A vulnerability (CVE-2021-44832) was disclosed on December 28th where an attacker having access and permission to write the Log4j configuration file can result in Remote Code Execution. ~~APM Java Agent has no known vulnerabilities to CVE-2021-44832 as the ability to modify the log4j configurations is not exposed by default.~~ [Jan 11] CVE-2021-44832 may be exploited in versions 1.27.0, 1.27.1, 1.28.0, and 1.28.1 if an attacker has access to create files within your application directory The latest APM Java Agent versions are updated to include Log4j 2.12.4. ### [Update Dec 22] APM Java Agent 1.26.1 and 1.28.3 are now available. Both include log4j2 2.12.3 which fully addresses CVE-2021-45046 and CVE-2021-45105. Users running APM Java Agent <=1.26.0 are advised to select 1.26.1 in order to move to a version with a fully-patched log4j with minimal qualification required of other changes in the APM Java Agent. Users who have already adopted Java APM Agent >= 1.27.0 can move forward to the latest which is APM Java Agent 1.28.3. ### [Update Dec 20] APM Java Agent has no known vulnerabilities to CVE-2021-45105. Regardless, we do intend to remain current on log4j and plan to update the APM Java Agent after log4j 2.12.3 becomes available. ### [Update Dec 17] We have now released 1.28.2, which ships with a patched log4j version (2.12.2) that should not trigger false positive alerts from vulnerability scanners. ### [Update Dec 15] Version 1.28.1 of the Elastic APM Java agent also mitigates CVE-2021-45046, as we have excluded the vulnerable JndiLookup class. This version still uses log4j 2.12.1 but the vulnerable code is not present. We will release 1.28.2 soon, which ships with a patched log4j version (2.12.2) that should not trigger false positive alerts from vulnerability scanners. ### APM Java Agent mitigation summary matrix Note: While the below mitigations are considered complete, **our overall recommendation is to update <=1.26.0 to 1.26.1 and >=1.27.0 to 1.28.3** _Yes_ indicates the versions are subject to the vulnerability in question, _No_ indicates they are not vulnerable. Version ranges are inclusive. Java Agent | CVE IDs | Information Leak | Remote Code Execution | Complete Mitigation ---|---|---|---|--- 1.28.4 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A (not vulnerable) log4j updated to 2.12.3 1.28.3 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A (not vulnerable) log4j updated to 2.12.3 1.28.2 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A (not vulnerable) log4j updated to 2.12.2 1.28.1 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A (not vulnerable) JndiLookup removed 1.26.2 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A (not vulnerable) log4j updated to 2.12.4 1.26.1 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A (not vulnerable) log4j updated to 2.12.3 1.27.0-1.28.0 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | Yes 2,3 | Yes 2,3 | System property 1 1.17.0-1.26.0 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | Yes 2 | Yes 2 | System property 1 File system permission 4 1.0.0-1.16.0 | CVE-2021-44228, CVE-2021-45046, CVE-2021-45046, CVE-2021-45105 | No | No | N/A - Log4j not used 1 Set the JVM option -Dlog4j2.formatMsgNoLookups=true and restart your application. This is a complete mitigation where noted above. The Elastic APM Java Agent has no known vulnerabilities to Thread Context Message and Context Lookup from CVE-2021-45046. 2 The only known way the Log4j vulnerability may be exploited is when the APM Java Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format (log_format_stdout/log_format_file=PLAIN_TEXT). 3 Only CVE-2021-44832 if an attacker can create files within your application directory 4 Ensure that correct filesystem permissions prevents unauthorized file creation * * * ## Elasticsearch announcement (ESA-2021-31) Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch running on JDK8 or below is susceptible to an information leak via DNS which is fixable by the JVM option identified below. This option is effective for Elasticsearch versions 5.6.11+, 6.4+, and 7.0+. As of December 13, 2021, we have released Elasticsearch 6.8.21 and 7.16.1 which set the JVM option identified below and remove the vulnerable JndiLookup class from Log4j out of an abundance of caution. If you are on a 6.x version prior to 6.4.0 and upgrading is not possible, you can follow the instructions here. Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. For versions 5.6.11 - 5.6.16, this can be mitigated by setting the JVM option. Users on an earlier version of 5.x, are recommended to upgrade to 5.6.16. If you are on a 5.x version prior to 5.6.11 and upgrading is not possible, you can follow the instructions here. Please note that while we provide these remediations, Elasticsearch 5 is not a supported version, and we always recommend updating to the latest release. Elasticsearch 2 and earlier used a Log4j version that is not vulnerable to the newly discovered flaw. Please note that Elasticsearch 2 is not a supported version, and we always recommend updating to the latest release. For users running on Elastic Cloud, versions 7.2+ have never been susceptible to either the RCE or the information leakage as these versions already run on JDK11 or higher. We recommend users running any version of Elasticsearch earlier than 7.2 restart their clusters as soon as possible - the JVM option identified below will automatically be applied and fully protect clusters on restart. Any new clusters will be deployed with the JVM option included. See Elastic Cloud announcement for more details **Affected Versions:** Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j. Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. We’ve confirmed that the Security Manager mitigates the remote code execution attack in Elasticsearch 6 and 7. **Solutions and Mitigations:** The simplest remediation is to set the JVM option -Dlog4j2.formatMsgNoLookups=true and restart each node of the cluster. For Elasticsearch 5.6.11+, 6.4+, and 7.0+, this provides full protection against the RCE and information leak attacks. Users may upgrade to Elasticsearch 7.16.2 or 6.8.22, which were released on December 19, 2021 and updates Log4j to the most recent version (2.17.0). The previous 7.16.1 and 6.8.21 releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package. Note: Prior to 7.16.2 and 6.8.22, some vulnerability scanners may continue to flag Elasticsearch in association with this vulnerability based on the Log4j version alone. However, any of the above mitigations sufficiently protect both remote code execution and information leakage. ### [Update Jan 6] By default, Elasticsearch’s log4j2.properties configuration file is only writable to the administrators of the cluster. If you have modified your file system permissions to grant non-admins write access to this file, then you may be susceptible to CVE-2021-44832, and should take steps to ensure that Elasticsearch’s configuration files are only writable by cluster administrators. **We will release 7.16.3 and 6.8.23 to update Log4j to 2.17.1, targeting Jan 13.** ### [Update Dec 19] Elastiscsearch 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not cause false positives in vulnerability scanners. ### [Update Dec 14] Log4j 2.16.0 has been released to address CVE-2021-45046. This does not change the mitigation guidance for Elasticsearch described above, that does not require an update to Log4j 2.16.0. Elastic guidance remains to either apply the JVM option described above and restart all nodes, or upgrade Elasticsearch to 7.16.1 or 6.8.21. ### Elasticsearch with ECK If Elasticsearch is managed by **ECK** , set the JVM option in the Elasticsearch custom resource podTemplate specification or upgrade to ECK 1.9.1 which automatically adds the JVM option to impacted Elasticsearch clusters. ### Elasticsearch with ECE If Elasticsearch is managed by **ECE** , for versions 6.x and <7.2, we recommend reinstalling stackpacks, which have been patched to include the JVM option mitigation. After re-installing relevant stackpacks, we recommend restarting deployments. For the 5.x series, we recommend overriding the JVM options to add the property that will mitigate the vulnerability, and restart the cluster to pick up the change: For details and guidance, please reach out to Elastic support. ### Details on Elasticsearch information leakage The information leakage vulnerability in Log4j enables an attacker to exfiltrate certain environmental data via DNS - it does not permit access to data within the Elasticsearch cluster. The data that can be leaked is limited to those available via Log4j “lookups”, which includes system environment variables and a limited set of environmental data from other sources. For a complete list, see the Log4j Lookups documentation. ### Notes of PoCs expanding RCEs to recent Java versions** We are actively monitoring developments in the security community, such as this one, which seek to expand the JDKs and scenarios where this exploit will apply. Our implementation of the Java Security Manager in Elasticsearch 6 and 7, in combination with JDK9 or greater, continues to protect against all known PoC’s. While these efforts seek to provide a viable RCE even when com.sun.jndi.ldap.object.trustURLCodebase=false (as in recent JDKs), our Security Manager cuts off the attack earlier in the process, preventing both remote and local (on the class path) variants of the attack. ### Elasticsearch mitigation summary matrix Note: While the below mitigations are considered complete, **our overall recommendation is to update to version 7.16.3 or 6.8.23 or newer.** _Yes_ indicates the versions are subject to the vulnerability in question, _No_ indicates they are not vulnerable. Version ranges are inclusive. Elasticsearch | JDK | CVE IDs | Information Leak | Remote Code Execution | Complete Mitigation ---|---|---|---|---|--- 7.16.1 - 7.16.2 | ≥ 8 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 7.0.0 - 7.16.0 | ≥ 9 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A3 (not vulnerable) 7.0.0 - 7.16.0 | < 9 | CVE-2021-44228, CVE-2021-45046 | Yes | No | System property1 6.8.21 | ≥ 8 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 6.0.0 - 6.8.20 | ≥ 9 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A3 (not vulnerable) 6.4.0 - 6.8.20 | < 9 | CVE-2021-44228, CVE-2021-45046 | Yes | No | System property1 6.0.0 - 6.3.2 | < 9 | CVE-2021-44228, CVE-2021-45046 | Yes | No | Remove JndiLookup2 5.6.11 - 5.6.16 | 8 | CVE-2021-44228, CVE-2021-45046 | Yes | Yes | System property1 5.0.0 - 5.6.10 | 8 | CVE-2021-44228, CVE-2021-45046 | Yes | Yes | Remove JndiLookup2 < 5.0.0 | any | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 1Set the JVM option -Dlog4j2.formatMsgNoLookups=true on each node and restart each node. This is a complete mitigation where noted above. Elasticsearch has no known vulnerabilities to Thread Context Message and Context Lookup from CVE-2021-45046. 2Removal of the JndiLookup class from the Log4j library. Instructions here. 3No mitigation is needed as this configuration is not vulnerable. On Elasticsearch 6.4.0 or higher, you can still add the system property in an abundance of caution. * * * ## Logstash announcement (ESA-2021-31) A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. Logstash uses Log4j as its logging subsystem and may be vulnerable. When running Logstash on JDKs older than 8u191 and 11.0.1, an attacker is able to inject and execute a remote Java class. On recent JDKs the attack is limited to DoS - causing data ingestion to temporarily stop - and information leakage, but no remote code execution attack vectors are known. **Affected Versions:** Logstash versions 5.0.0+ up to and including 7.16.0 contain a vulnerable version of Log4j. The severity depends on the JDK used as stated above. Docker images below version 6.4.3 include a JDK older than 8u191, which means they are open to Remote Code Execution. Images 6.4.3+ don't have known RCE attacks but are still susceptible to Denial of Service and information leaks. **Solutions and Mitigations:** Users should upgrade to Logstash 7.16.3 or 6.8.23. These releases replace vulnerable versions of Log4j with Log4j 2.17.1. The widespread flag -Dlog4j2.formatMsgNoLookups=true is NOT sufficient to mitigate the vulnerability in Logstash in all cases, as Logstash uses Log4j in a way where the flag has no effect. If the user cannot upgrade to Logstash 7.16.2 or 6.8.22, it is necessary to remove the JndiLookup class from the log4j2 core jar, with the following command (which is applicable for 5.x, 6.x, and 7.x): `zip -q -d /logstash-core/**/*/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class` Please note that a restart of the Logstash process is necessary for the change to take effect. ### [Update Jan 6] By default, Logstash’s log4j2.properties configuration file is only writable to the local administrator. If you have modified your file system permissions to grant non-admins write access to this file, then you may be susceptible to CVE-2021-44832, and should take steps to ensure that Logstash’s configuration files are only writable by administrators. **We will release 7.16.3 and 6.8.23 to update Log4j to 2.17.1, targeting Jan 13.** ### [Update Dec 19] Logstash 7.16.2 and 6.8.22 are now released, these releases include Log4j 2.17.0 and should not cause false positives in vulnerability scanners. ### [Update Dec 15] Users have noticed that the newly released Logstash 6.8.21 contains a jar that bundles a vulnerable version of log4j-core. Logstash core will load the Log4j 2.15.0 from core instead of any other log4j-core jar in plugins, so no Jndi Lookups will happen. ### [Update Dec 14] Log4j 2.16.0 has been released to address CVE-2021-45046. Logstash is not impacted by the vulnerability disclosed in CVE-2021-45046 because Logstash does not ship with logging layouts that can be exploited to trigger JNDI lookups through Thread Context references. Elastic guidance remains to either remove the JndiLookup.class or upgrade Logstash to 7.16.1 or 6.8.21. The fact that the logj4-core 2.15.0 from core is the only one loaded has been confirmed through code analysis and experimentation, but if users are required to remove the class, the command is: `zip -q -d /vendor/**/*/logstash*tcp*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` ### Logstash mitigation summary matrix Note: While the below mitigations are considered complete, **our overall recommendation is to update to version 7.16.3 or 6.8.23 or newer.** _Yes_ indicates the versions are subject to the vulnerability in question, _No_ indicates they are not vulnerable. Version ranges are inclusive. Logstash | JDK | CVE IDs | Information Leak | Remote Code Execution | Complete Mitigation ---|---|---|---|---|--- 7.16.1 - 7.16.2 | ≥ 8 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 7.0.0 - 7.16.0 | ≥ 8u191 ≥ 11.0.1 | CVE-2021-44228, CVE-2021-45046 | Yes | No | Remove JndiLookup.class1 7.0.0 - 7.16.0 | < 8u191 < 11.0.1 | CVE-2021-44228, CVE-2021-45046 | Yes | Yes | Remove JndiLookup.class1 6.8.21 | ≥ 8 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 5.0.0 - 6.8.20 | ≥ 8u191≥ 11.0.1 | CVE-2021-44228, CVE-2021-45046 | Yes | No | Remove JndiLookup.class1 5.0.0 - 6.8.20 | < 8u191 < 11.0.1 | CVE-2021-44228, CVE-2021-45046 | Yes | Yes | Remove JndiLookup.class1 < 5.0.0 | Any | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 1Removal of the JndiLookup class from the Log4j library. Instructions here. * * * ## Elastic Cloud announcement (ESA-2021-31) Our security testing has not identified any exploitable RCEs against any Elastic Cloud products. Our investigation continues and we will provide updates of any new findings. As a normal practice we will update components with the latest version of Log4j as they become available. Users runningElastic Cloud versions 7.2+ have never been susceptible to either the RCE or the information leakage as these versions already run on JDK 11 or higher. **Solutions and Mitigations:** Deployments hosted in Elastic Cloud have been updated to leverage the JVM Option -Dlog4j2.formatMsgNoLookups=true which will take effect on restart of the deployment and on any config change to the Elasticsearch deployment. For users running a cluster on a minor version older than 7.2, we recommend a restart. The simplest way to restart a deployment is to do the following: 1. Log in to the Cloud UI. Navigate to the “deployments” section in Elasticsearch Service. 2. Select the deployment you’d like to restart. 3. In the “manage” menu, select “restart”. Any kind of restart will work: “no downtime” restarts are fine. ### Elasticsearch on Elastic Cloud mitigation summary matrix Note: While the below mitigations are considered complete, **our overall recommendation is to update to version 7.16.3 or 6.8.23 or newer.** Yes indicates the versions are subject to the vulnerability in question, No indicates they are not vulnerable. Version ranges are inclusive. Elasticsearch | CVE IDs | Information Leak | Remote Code Execution | Complete Mitigation ---|---|---|---|--- 7.16.1 - 7.16.2 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 7.2.0 - 7.16.0 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A2 (not vulnerable) 7.0.0 - 7.1.1 | CVE-2021-44228, CVE-2021-45046 | Yes | No | Restart1 6.8.21 | CVE-2021-44228, CVE-2021-45046 | No | No | N/A (not vulnerable) 6.0.0 - 6.8.20 | CVE-2021-44228, CVE-2021-45046 | Yes | No | Restart1 5.5.0 - 5.6.16 | CVE-2021-44228, CVE-2021-45046 | Yes | Yes | Restart1 5.0.0 - 5.4.3 | CVE-2021-44228, CVE-2021-45046 | Yes | Yes | Upgrade 1 Run a no-downtime restart on your deployment. Instructions here. 2 Running a restart as in 1 will enable the system property in an abundance of caution. * * *