I researched the necessary responses for Apache Log4j vulnerability and Elasticsearch, so I’ll introduce them.
Background: Apache Log4j Vulnerability Response
For Apache Log4j vulnerability, please read Summary of Log4j’s Serious Vulnerability CVE-2021-44228 - piyolog (Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog).
Product information stating no impact is also being updated, and as of December 13, 2021, no affected products have been confirmed for Paloalto, Pulse Secure, SonicWall, and ElasticSearch.
(影響無しとする製品情報もアップデートが進められており、Paloalto、Pulse Secure、SonicWall、ElasticSearchで影響を受ける製品は2021年12月13日時点で確認されていない。)
Impact Scope of Log4j Vulnerability on Elasticsearch
If you’re not using Elasticsearch on JDK8 or below, there seemed to be no problem.
**Elasticsearch**Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch on JDK8 or below is susceptible to an information leak via DNS which is fixed by a simple JVM property change. The information leak does not permit access to data within the Elasticsearch cluster. We will also release a new version of Elasticsearch that contains the JVM property by default and removes certain components of Log4j out of an abundance of caution. Additional details below.
That’s all from the Gemba on the Apache Log4j vulnerability and its impact on Elasticsearch.