# 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:** 1
**Showing post:** 37

<div class="post-metadata">

### Author: ![jsvd](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jsvd/32/6203_2.png) [@jsvd](https://discuss.elastic.co/u/jsvd)
#### Post date: [December 12, 2021, 4:42pm UTC](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439/37 "2021-12-12T16:42:44Z")

</div>

Please be aware that it's possible to trigger a JNDI lookup from an input plugin, before any filter kicks in, therefore I'd refrain from relying on this workaround.  
The only known mitigation until the release is out is to remove the class from the log4j jar as stated in the [advisory](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476).

---

_[View the full topic](https://discuss.elastic.co/t/zero-day-exploit-in-log4j2-which-is-part-of-elasticsearch/291439)._