# Elasticsearch 8.18.4 has uncontrolled recursion CVE **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security, docker\ **Created:** [July 25, 2025, 7:23pm UTC](https://discuss.elastic.co/t/elasticsearch-8-18-4-has-uncontrolled-recursion-cve/380477 "2025-07-25T19:23:58Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Doc\_Kaos](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/doc_kaos/32/53671_2.png) [@Doc\_Kaos](https://discuss.elastic.co/u/Doc_Kaos)\ **Post date:** [July 25, 2025, 7:23pm UTC](https://discuss.elastic.co/t/elasticsearch-8-18-4-has-uncontrolled-recursion-cve/380477/1 "2025-07-25T19:23:58Z")
Hey team, we're looking at ES 8.18.4 and getting an issues with an uncontrolled recursion vulnerability from Snyk. Can anyone tell me if this is already in the works, or a ticket I can link to for my team? Testing [docker.elastic.co/elasticsearch/elasticsearch:8.18.4](http://docker.elastic.co/elasticsearch/elasticsearch:8.18.4)... Tested 8 dependencies for known issues, found 1 issue. Issues to fix by upgrading: Upgrade org.apache.commons:commons-lang3@3.9 to org.apache.commons:commons-lang3@3.18.0 to fix ✗ Uncontrolled Recursion (new) [High Severity][[Uncontrolled Recursion in org.apache.commons:commons-lang3 | CVE-2025-48924 | Snyk](https://security.snyk.io/vuln/SNYK-JAVA-ORGAPACHECOMMONS-10734078)] in org.apache.commons:commons-lang3@3.9 introduced by org.apache.commons:commons-lang3@3.9 ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [July 28, 2025, 2:07pm UTC](https://discuss.elastic.co/t/elasticsearch-8-18-4-has-uncontrolled-recursion-cve/380477/2 "2025-07-28T14:07:28Z")
We can't discuss security vulnerabilities in public channels such as this forum, sorry. Please [follow these instructions about reporting potential security vulnerabilities](https://www.elastic.co/community/security) instead. Note that a published vulnerability in a dependency does not indicate whether Elasticsearch itself has a similar vulnerability. It may be that Elasticsearch uses the dependency in a way that prevents the issue from occurring.