# Log4j Vulnerability Elasticsearch 7.8.0
**URL:** https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035
**Category:** Elasticsearch
**Created:** [May 10, 2023, 7:42am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035 "2023-05-10T07:42:25Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Faisal\_Umer](https://discuss.elastic.co/u/Faisal_Umer)
#### Post date: [May 10, 2023, 7:42am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/1 "2023-05-10T07:42:26Z")
We have Elasticsearch 7.8.0 cluster which has CVE-2021-44228. Can we somehow patch it without upgrading the Elasticsearch version? If yes, can you please share any relevant thread or documentation?
---
### Author:  [@mikewillis](https://discuss.elastic.co/u/mikewillis)
#### Post date: [May 10, 2023, 8:48am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/2 "2023-05-10T08:48:39Z")
> [@Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476):
>
> 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 pl…
Search for "Elasticsearch announcement (ESA-2021-31)". There's information about how to mitigate by setting `-Dlog4j2.formatMsgNoLookups=true`
---
### Author:  [@Faisal\_Umer](https://discuss.elastic.co/u/Faisal_Umer)
#### Post date: [May 12, 2023, 7:13am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/3 "2023-05-12T07:13:13Z")
Thank you for your prompt response @mikewillis. Can you recommend the best way to update this config on a multinode cluster as we have a considerable cluster size and it would be time taking to update the configs on one node at a time and moving the data around?
---
### Author:  [@mikewillis](https://discuss.elastic.co/u/mikewillis)
#### Post date: [May 12, 2023, 12:37pm UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/4 "2023-05-12T12:37:16Z")
I'd say the best way do deploy a configuration change to every node is using your configuration management, e.g. Ansible or Puppet, that you used to build the cluster with, but since you're asking the question you presumably don't have configuration management. If you're running it all on Linux and have key auth set up then you could script it. But again, since you're asking… How you deploy configuration changes is really is a systems administration question rather than an Elasticsearch question.
I'm not sure why you're mentioning moving data around. Do you need to move data on your cluster around to reboot a node? Or are you just referring to it can take a significant amount of time to go through the process to rebooting a node, waiting for cluster health to go Green again, reboot another node etc?
Increasing the value of `index.unassigned.node_left.delayed_timeout` to something greater then the amount of time it takes for a node to be rebooted and rejoin the cluster will reduce the amount of time it takes for cluster health to reach Green by reducing the amount of work the cluster does as a result of a node being rebooted. E.g. If it takes five minutes for a node to reboot and rejoin then setting the value to `6m` should mean that the cluster doesn't start recreating missing replica shards before the node rejoins.
---
### Author:  [@mikewillis](https://discuss.elastic.co/u/mikewillis)
#### Post date: [May 12, 2023, 1:45pm UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/5 "2023-05-12T13:45:49Z")
Just realised I meant to include link to [Delaying allocation when a node leaves | Elasticsearch Guide [7.8] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/7.8/delayed-allocation.html)
---
### Author:  [@Faisal\_Umer](https://discuss.elastic.co/u/Faisal_Umer)
#### Post date: [June 1, 2023, 7:10am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/6 "2023-06-01T07:10:35Z")
Thank you for sharing this. I have tried applying the setting to increase the time out to delay the shards rebalancing
```auto
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
```
but getting the following error.
```auto
{
"error" : {
"root_cause" : [
{
"type" : "security_exception",
"reason" : "no permissions for [] and User [name=, backend_roles=[admin], requestedTenant=null]"
}
],
"type" : "security_exception",
"reason" : "no permissions for [] and User [name=, backend_roles=[admin], requestedTenant=null]"
},
"status" : 403
}
```
Although, I have the following admin permissions assigned to my user.
```auto
{
"description": "Allow full access to all indices and all cluster APIs",
"index_permissions": [
{
"index_patterns": [
"*"
],
"fls": [],
"masked_fields": [],
"allowed_actions": [
"*"
]
}
],
"tenant_permissions": [
{
"tenant_patterns": [
"*"
],
"allowed_actions": [
"kibana_all_write"
]
}
],
"cluster_permissions": [
"*"
]
}
```
Am I missing any permissions that are required?
We are using OKTA for user management. Is it possible that I have admin assigned to me in Elasticsearch and different levels of permissions are enforced from the OKTA side?
---
### Author:  [@Faisal\_Umer](https://discuss.elastic.co/u/Faisal_Umer)
#### Post date: [June 6, 2023, 4:52am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/7 "2023-06-06T04:52:56Z")
@mikewillis can you please advise here?
---
### Author:  [@mikewillis](https://discuss.elastic.co/u/mikewillis)
#### Post date: [June 6, 2023, 8:08am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/8 "2023-06-06T08:08:01Z")
I have no familiarity with OKTA. Trying to get help for a completely unrelated problem in the replies is generally not the best way to go about things. I advise you make a new post about your new problem so that it gets visibility. Though OKTA appears to to be a third party add on for Elasticsearch so you're probably more likely to get a good response to a question about it somewhere dedicated to support of OKTA.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 4, 2023, 8:08am UTC](https://discuss.elastic.co/t/log4j-vulnerability-elasticsearch-7-8-0/333035/9 "2023-07-04T08:08:31Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.