# CVE-2021-44228 Alternative Mitigation
**URL:** https://discuss.elastic.co/t/cve-2021-44228-alternative-mitigation/291877
**Category:** Logstash
**Created:** [December 14, 2021, 10:18pm UTC](https://discuss.elastic.co/t/cve-2021-44228-alternative-mitigation/291877 "2021-12-14T22:18:14Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@boris111](https://discuss.elastic.co/u/boris111)
#### Post date: [December 14, 2021, 10:18pm UTC](https://discuss.elastic.co/t/cve-2021-44228-alternative-mitigation/291877/1 "2021-12-14T22:18:14Z")
Is it possible to drop the new log4j-core-2.15.0.jar for logstash as an alternative mitigation for the 5.x logstash version? The recommended mitigation step to remove the JndiLookup.class would not be desirable for deployments as our scanners will still flag it as non-compliant. Is there any configuration files that requires updating?
Is it possible to simply replace these references found below?
```auto
grep -rnw /opt/elastic -e 'log4j.*2\.6'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:6: require 'org/apache/logging/log4j/log4j-core/2.6.2/log4j-core-2.6.2.jar'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:14: require 'org/apache/logging/log4j/log4j-api/2.6.2/log4j-api-2.6.2.jar'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:15: require 'org/apache/logging/log4j/log4j-slf4j-impl/2.6.2/log4j-slf4j-impl-2.6.2.jar'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:23: require_jar 'org.apache.logging.log4j', 'log4j-core', '2.6.2'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:31: require_jar 'org.apache.logging.log4j', 'log4j-api', '2.6.2'
/opt/elastic/logstash-5.6.16/logstash-core/lib/logstash-core_jars.rb:32: require_jar 'org.apache.logging.log4j', 'log4j-slf4j-impl', '2.6.2'
/opt/elastic/logstash-5.6.16/logstash-core/gemspec_jars.rb:5:gem.requirements << "jar org.apache.logging.log4j:log4j-slf4j-impl, 2.6.2"
/opt/elastic/logstash-5.6.16/logstash-core/gemspec_jars.rb:6:gem.requirements << "jar org.apache.logging.log4j:log4j-api, 2.6.2"
/opt/elastic/logstash-5.6.16/logstash-core/gemspec_jars.rb:7:gem.requirements << "jar org.apache.logging.log4j:log4j-core, 2.6.2"
/opt/elastic/logstash-5.6.16/vendor/bundle/jruby/1.9/gems/logstash-input-beats-3.1.32-java/lib/logstash-input-beats_jars.rb:11:require_jar('org.apache.logging.log4j', 'log4j-api', '2.6.2')
```
---
### Author:  [@yaauie](https://discuss.elastic.co/u/yaauie)
#### Post date: [December 15, 2021, 4:18am UTC](https://discuss.elastic.co/t/cve-2021-44228-alternative-mitigation/291877/2 "2021-12-15T04:18:21Z")
In addition to replacing those references, you would also need to replace the vendored log4j jars themselves, and you would be somewhat on your own with a custom hand-rolled mitigation. Bear in mind that Elastic-released artifacts go through somewhat _extensive_ testing and validation, in this case not only for base functionality but also explicit validation for addressing the related CVE.
Out guidance remains to remove the JNDI lookup class, or to upgrade to a patched releases:
> [@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/1):
>
> **Elastic guidance remains to either remove the JndiLookup.class or upgrade Logstash to 7.16.1 or 6.8.21.**
---
### Author:  [@boris111](https://discuss.elastic.co/u/boris111)
#### Post date: [December 15, 2021, 7:55pm UTC](https://discuss.elastic.co/t/cve-2021-44228-alternative-mitigation/291877/3 "2021-12-15T19:55:02Z")
Since our organization will be scanning across the board the idea of making an exception for this component will not be desirable... We also prefer this mitigation because we can verify the integrity of the delivered jar against the checksum as known in the maven repositories.
After replacing the files and their references with the 2.16.0 versions everything seems to be working as expected. We will do more detailed testing with this mitigation as we move forward with testing the rollout.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [January 12, 2022, 7:55pm UTC](https://discuss.elastic.co/t/cve-2021-44228-alternative-mitigation/291877/4 "2022-01-12T19:55:08Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.