# Zero-day-exploit in log4j2 which is part of elasticsearch
**URL:** https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439
**Category:** Elasticsearch
**Created:** [December 10, 2021, 3:46pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439 "2021-12-10T15:46:15Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@sandeepkanabar](https://discuss.elastic.co/u/sandeepkanabar)
#### Post date: [December 14, 2021, 8:13pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/65 "2021-12-14T20:13:27Z")
Probably permissions issue. That's why Elasticsearch is not starting. If you have removed class from the jar, check the permissions of the jar and make sure it is `elasticsearch:elasticsearch` or whatever it was before.
---
### Author:  [@satishkovuru](https://discuss.elastic.co/u/satishkovuru)
#### Post date: [December 14, 2021, 9:47pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/66 "2021-12-14T21:47:44Z")
> [@sandeepkanabar](#):
>
> `elasticsearch:elasticsearch`
Getting this error, I checked all the files are having correct permissions
# systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2021-12-14 15:46:01 CST; 11s ago
Docs: [https://www.elastic.co](https://www.elastic.co)
Process: 27692 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID\_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAILURE)
Main PID: 27692 (code=exited, status=1/FAILURE)
Dec 14 15:46:00 systemd-entrypoint[27692]: Caused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.Level
Dec 14 15:46:00 systemd-entrypoint[27692]: at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
Dec 14 15:46:00 systemd-entrypoint[27692]: at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
Dec 14 15:46:00 systemd-entrypoint[27692]: at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
Dec 14 15:46:00 systemd-entrypoint[27692]: ... 3 more
Dec 14 15:46:01 systemd-entrypoint[27692]: Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/logging/log4j/status/StatusListener
Dec 14 15:46:01 systemd[1]: elasticsearch.service: main process exited, code=exited, status=1/FAILURE
Dec 14 15:46:01 systemd[1]: Failed to start Elasticsearch.
Dec 14 15:46:01 systemd[1]: Unit elasticsearch.service entered failed state.
Dec 14 15:46:01 systemd[1]: elasticsearch.service failed.
---
### Author:  [@Mirang\_Parikh](https://discuss.elastic.co/u/Mirang_Parikh)
#### Post date: [December 15, 2021, 7:21am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/67 "2021-12-15T07:21:22Z")
We are using Elasticsearch 7.14.1. With this version we have log4j-api-2.11.1.jar and log4j-core-2.11.1.jar, being shipped to customers. Apart from the above mentioned workaround and possible fixes, is it possible to simply replace log4j-api-2.11.1.jar with log4j-api-2.16.0.jar and log4j-core-2.11.1.jar with log4j-core-2.16.0.jar to completely remove the vulnerable jar file? Would you recommend that also as one fix apart from the above workarounds ? This is because customers are concerned of having some vulnerable components on their systems and are more interested in removing the problem itself(here the log4j 2.11 jar), rather than having some workaround or fixes with the vulnerable component.
---
### Author:  [@NominaSumpta](https://discuss.elastic.co/u/NominaSumpta)
#### Post date: [December 15, 2021, 8:45am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/68 "2021-12-15T08:45:41Z")
Is the Elastic team aware of the new CVE-2021-45046?
---
### Author:  [@sandeepkanabar](https://discuss.elastic.co/u/sandeepkanabar)
#### Post date: [December 15, 2021, 9:55am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/69 "2021-12-15T09:55:32Z")
Yes. They are. Their [advisory](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476) does mention it at the very top.
---
### Author:  [@commonorbit](https://discuss.elastic.co/u/commonorbit)
#### Post date: [December 15, 2021, 10:24am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/70 "2021-12-15T10:24:52Z")
Is there more information on what makes Elasticsearch 5 vulnerable? We're having difficulty duplicating the vulnerability and the version of log4j in question appears (_appears_) to not be vulnerable: [elasticsearch/apache-log4j-extras-DEPENDENCIES at 5.6 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/blob/5.6/core/licenses/apache-log4j-extras-DEPENDENCIES#L14)
---
### Author:  [@NominaSumpta](https://discuss.elastic.co/u/NominaSumpta)
#### Post date: [December 15, 2021, 10:40am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/71 "2021-12-15T10:40:51Z")
Seems like I was looking at a cached page. Thanks.
---
### Author:  [@Mirang\_Parikh](https://discuss.elastic.co/u/Mirang_Parikh)
#### Post date: [December 15, 2021, 10:44am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/72 "2021-12-15T10:44:06Z")
@sandeepkanabar any idea on this ?
---
### Author:  [@sandeepkanabar](https://discuss.elastic.co/u/sandeepkanabar)
#### Post date: [December 15, 2021, 12:41pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/73 "2021-12-15T12:41:59Z")
> [@commonorbit](#):
>
> elasticsearch/apache-log4j-extras-DEPENDENCIES at 5.6 · elastic/elasticsearch · GitHub
Hi @Mirang_Parikh - I don't know the answer to your question. But this is something you can verify with a quick POC. Try upgrading the log4j jars and make sure permissions and owner is correctly set and then do a few CRUD operations and see if all works. You might want to look at [this](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/64) though.
But the ideal scenario is to follow **Elastic advisory**. As per the updated advisory
_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._
---
### Author:  [@sandeepk-veritas](https://discuss.elastic.co/u/sandeepk-veritas)
#### Post date: [December 15, 2021, 1:01pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/74 "2021-12-15T13:01:11Z")
@sandeepkanabar I tried that and observed that Elasticsearch 7.14.1/7.15.0 does not startup cleanly. We get following errors:
```auto
[2021-12-15T14:02:22,438][ERROR][o.e.b.Bootstrap] [SK-FS-2K19] Exception
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) ~[?:?]
at java.security.AccessController.checkPermission(AccessController.java:1036) ~[?:?]
at java.lang.SecurityManager.checkPermission(SecurityManager.java:408) ~[?:?]
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:2049) ~[?:?]
at java.lang.ClassLoader.getParent(ClassLoader.java:1799) ~[?:?]
at org.apache.logging.log4j.util.LoaderUtil.getClassLoaders(LoaderUtil.java:113) ~[log4j-api-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.util.WatchManager.getEventServices(WatchManager.java:160) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.util.WatchManager.(WatchManager.java:137) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:137) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.config.DefaultConfiguration.(DefaultConfiguration.java:46) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.layout.PatternLayout$Builder.build(PatternLayout.java:768) ~[log4j-core-2.16.0.jar:2.16.0]
at org.elasticsearch.xpack.deprecation.logging.EcsJsonLayout.(EcsJsonLayout.java:47) ~[?:?]
at org.elasticsearch.xpack.deprecation.logging.EcsJsonLayout.createLayout(EcsJsonLayout.java:124) ~[?:?]
at org.elasticsearch.xpack.deprecation.logging.EcsJsonLayout$Builder.build(EcsJsonLayout.java:150) ~[?:?]
at org.elasticsearch.xpack.deprecation.logging.DeprecationIndexingComponent.(DeprecationIndexingComponent.java:70) ~[?:?]
at org.elasticsearch.xpack.deprecation.Deprecation.createComponents(Deprecation.java:83) ~[?:?]
at org.elasticsearch.node.Node.lambda$new$18(Node.java:615) ~[elasticsearch-7.14.1.jar:7.14.1]
at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273) ~[?:?]
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) ~[?:?]
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
at org.elasticsearch.node.Node.(Node.java:619) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.node.Node.(Node.java:281) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Bootstrap$5.(Bootstrap.java:219) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:219) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:399) [elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) [elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) [elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:75) [elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:116) [elasticsearch-cli-7.14.1.jar:7.14.1]
at org.elasticsearch.cli.Command.main(Command.java:79) [elasticsearch-cli-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:115) [elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:81) [elasticsearch-7.14.1.jar:7.14.1]
[2021-12-15T14:02:22,454][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [SK-FS-2K19] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:163) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:150) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:75) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:116) ~[elasticsearch-cli-7.14.1.jar:7.14.1]
at org.elasticsearch.cli.Command.main(Command.java:79) ~[elasticsearch-cli-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:115) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:81) ~[elasticsearch-7.14.1.jar:7.14.1]
Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) ~[?:?]
at java.security.AccessController.checkPermission(AccessController.java:1036) ~[?:?]
at java.lang.SecurityManager.checkPermission(SecurityManager.java:408) ~[?:?]
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:2049) ~[?:?]
at java.lang.ClassLoader.getParent(ClassLoader.java:1799) ~[?:?]
at org.apache.logging.log4j.util.LoaderUtil.getClassLoaders(LoaderUtil.java:113) ~[log4j-api-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.util.WatchManager.getEventServices(WatchManager.java:160) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.util.WatchManager.(WatchManager.java:137) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:137) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.config.DefaultConfiguration.(DefaultConfiguration.java:46) ~[log4j-core-2.16.0.jar:2.16.0]
at org.apache.logging.log4j.core.layout.PatternLayout$Builder.build(PatternLayout.java:768) ~[log4j-core-2.16.0.jar:2.16.0]
at org.elasticsearch.xpack.deprecation.logging.EcsJsonLayout.(EcsJsonLayout.java:47) ~[?:?]
at org.elasticsearch.xpack.deprecation.logging.EcsJsonLayout.createLayout(EcsJsonLayout.java:124) ~[?:?]
at org.elasticsearch.xpack.deprecation.logging.EcsJsonLayout$Builder.build(EcsJsonLayout.java:150) ~[?:?]
at org.elasticsearch.xpack.deprecation.logging.DeprecationIndexingComponent.(DeprecationIndexingComponent.java:70) ~[?:?]
at org.elasticsearch.xpack.deprecation.Deprecation.createComponents(Deprecation.java:83) ~[?:?]
at org.elasticsearch.node.Node.lambda$new$18(Node.java:615) ~[elasticsearch-7.14.1.jar:7.14.1]
at java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273) ~[?:?]
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) ~[?:?]
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
at org.elasticsearch.node.Node.(Node.java:619) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.node.Node.(Node.java:281) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Bootstrap$5.(Bootstrap.java:219) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:219) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:399) ~[elasticsearch-7.14.1.jar:7.14.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:159) ~[elasticsearch-7.14.1.jar:7.14.1]
... 6 more
```
Do you have any idea what could be reason behind them?
The same steps do work on 7.12.0, but that is not an option we can use. Our application already integrates 7.14.1.
---
### Author:  [@sandeepkanabar](https://discuss.elastic.co/u/sandeepkanabar)
#### Post date: [December 15, 2021, 1:08pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/75 "2021-12-15T13:08:09Z")
Can you share the output of `ls -l /usr/share/elasticsearch/lib/` or `ls -l
### Author:  [@sandeepk-veritas](https://discuss.elastic.co/u/sandeepk-veritas)
#### Post date: [December 15, 2021, 1:24pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/76 "2021-12-15T13:24:26Z")
We are using Windows.
```auto
Directory of E:\elasticsearch-7.14.1-windows-x86_64\elasticsearch-7.14.1\lib
12/15/2021 06:44 PM .
12/15/2021 06:44 PM ..
12/15/2021 01:58 PM 13,918,253 elasticsearch-7.14.1.jar
12/15/2021 01:58 PM 25,662 elasticsearch-cli-7.14.1.jar
12/15/2021 01:58 PM 69,236 elasticsearch-core-7.14.1.jar
12/15/2021 01:58 PM 52,995 elasticsearch-geo-7.14.1.jar
12/15/2021 01:58 PM 43,717 elasticsearch-launchers-7.14.1.jar
12/15/2021 01:58 PM 14,307 elasticsearch-plugin-classloader-7.14.1.jar
12/15/2021 01:58 PM 18,561 elasticsearch-secure-sm-7.14.1.jar
12/15/2021 01:58 PM 154,954 elasticsearch-x-content-7.14.1.jar
12/15/2021 01:58 PM 114,165 HdrHistogram-2.1.9.jar
12/15/2021 01:58 PM 1,159,086 hppc-0.8.1.jar
12/15/2021 01:58 PM 349,273 jackson-core-2.10.4.jar
12/15/2021 01:58 PM 58,567 jackson-dataformat-cbor-2.10.4.jar
12/15/2021 01:58 PM 90,817 jackson-dataformat-smile-2.10.4.jar
12/15/2021 01:58 PM 46,788 jackson-dataformat-yaml-2.10.4.jar
12/15/2021 01:58 PM 16,512 java-version-checker-7.14.1.jar
12/15/2021 01:58 PM 463,971 jna-5.7.0-1.jar
12/15/2021 01:58 PM 644,419 joda-time-2.10.10.jar
12/15/2021 01:58 PM 78,074 jopt-simple-5.0.2.jar
12/15/2021 01:58 PM 797,736 jts-core-1.15.0.jar
12/12/2021 11:35 PM 301,892 log4j-api-2.16.0.jar
12/12/2021 11:35 PM 1,789,565 log4j-core-2.16.0.jar
12/15/2021 01:58 PM 1,776,205 lucene-analyzers-common-8.9.0.jar
12/15/2021 01:58 PM 155,065 lucene-backward-codecs-8.9.0.jar
12/15/2021 01:58 PM 3,579,474 lucene-core-8.9.0.jar
12/15/2021 01:58 PM 98,341 lucene-grouping-8.9.0.jar
12/15/2021 01:58 PM 209,959 lucene-highlighter-8.9.0.jar
12/15/2021 01:58 PM 152,525 lucene-join-8.9.0.jar
12/15/2021 01:58 PM 52,141 lucene-memory-8.9.0.jar
12/15/2021 01:58 PM 105,985 lucene-misc-8.9.0.jar
12/15/2021 01:58 PM 381,773 lucene-queries-8.9.0.jar
12/15/2021 01:58 PM 382,661 lucene-queryparser-8.9.0.jar
12/15/2021 01:58 PM 223,460 lucene-sandbox-8.9.0.jar
12/15/2021 01:58 PM 240,654 lucene-spatial-extras-8.9.0.jar
12/15/2021 01:58 PM 309,351 lucene-spatial3d-8.9.0.jar
12/15/2021 01:58 PM 249,877 lucene-suggest-8.9.0.jar
12/15/2021 01:58 PM 682,804 lz4-java-1.8.0.jar
12/15/2021 01:58 PM 309,001 snakeyaml-1.26.jar
12/15/2021 01:58 PM 204,833 spatial4j-0.7.jar
12/15/2021 01:58 PM 51,208 t-digest-3.2.jar
12/15/2021 01:58 PM tools
40 File(s) 29,373,867 bytes
3 Dir(s) 8,790,441,984 bytes free
```
---
### Author:  [@sandeepkanabar](https://discuss.elastic.co/u/sandeepkanabar)
#### Post date: [December 15, 2021, 1:41pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/77 "2021-12-15T13:41:09Z")
@sandeepk-veritas - As I said earlier, the best option is to upgrade to ES 7.16.1 or else add the flag.
If the ES team kept the jar, _instead of upgrading it_, there might be a _good reason._
---
### Author:  [@bhulsman](https://discuss.elastic.co/u/bhulsman)
#### Post date: [December 15, 2021, 2:06pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/78 "2021-12-15T14:06:47Z")
Quick question; is a server safe when Elasticsearch is not running and it's ports aren't exposed to the outside world?
---
### Author:  [@codermonk](https://discuss.elastic.co/u/codermonk)
#### Post date: [December 16, 2021, 12:04am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/79 "2021-12-16T00:04:10Z")
If ES is not running, and thereby not listening on port, you are safe.
But if it’s running and even if server is not public, it still can be vulnerable. If the query you are sending to ES contains text from user input, maybe from other applications, it can be attacked.
---
### Author:  [@begin](https://discuss.elastic.co/u/begin)
#### Post date: [December 16, 2021, 1:11am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/80 "2021-12-16T01:11:03Z")
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](https://www.elastic.co/support/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+?
---
### Author:  [@TimV](https://discuss.elastic.co/u/TimV)
#### Post date: [December 16, 2021, 5:11am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/81 "2021-12-16T05:11:07Z")
> [@](#):
>
> 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](https://www.elastic.co/guide/en/elasticsearch/reference/7.16/advanced-configuration.html#set-jvm-options) `-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.
---
### Author:  [@begin](https://discuss.elastic.co/u/begin)
#### Post date: [December 16, 2021, 6:53am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/82 "2021-12-16T06:53:25Z")
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](https://www.elastic.co/support/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?
---
### Author:  [@UsmanNiazi](https://discuss.elastic.co/u/UsmanNiazi)
#### Post date: [December 16, 2021, 7:24am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/83 "2021-12-16T07:24:57Z")
Hi,
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)
Thanks
---
### Author:  [@TimV](https://discuss.elastic.co/u/TimV)
#### Post date: [December 16, 2021, 9:20am UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/84 "2021-12-16T09:20:07Z")
> [@begin](#):
>
> 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?
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.
[Previous page](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439.md?page=3)
[Next page](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439.md?page=5)