As part of the vulnerability assessment (VA) scan on our ELK servers, we identified that the OpenJDK version is affected by multiple vulnerabilities. We are using a self-managed cluster. We did upgrade the ELK stack from version 8.13.2 to 8.15.2, but the OpenJDK vulnerabilities still remain unresolved.
Our security team has suggested upgrading to an OpenJDK version greater than 22.0.1.
Is it possible to manually upgrade the bundled OpenJDK version? If so, how can this be done? If not, what is the recommended solution to resolve these vulnerabilities?
Alternatively, do we need to upgrade the entire ELK stack again, as we did previously, to a newer version? (This approach isn’t ideal, as it would require manual intervention each time a new VA is discovered.)
You cannot upgrade the bundled OpenJDK version, but you can install a different OpenJDK version and use it.
This is mentioned in the documentation that you linked.
To use your own version of Java, set the ES_JAVA_HOME environment variable to the path to your own JVM installation. The bundled JVM is located within the jdk subdirectory of the Elasticsearch home directory. You may remove this directory if using your own JVM.
Just install the OpenJDK version you want, and set the ES_JAVA_HOME on the system, and restart Elasticsearch.
We cannot discuss security vulnerabilities here in public, but it is worth noting that there have been 18 releases since 8.15.2, many of which bundle an OpenJDK version greater than 22.0.1.
And also highlighting the docs on the page you linked:
Bugs and security issues in the bundled JVM often relate to features that Elasticsearch does not use. Such issues do not apply to Elasticsearch. Elastic analyzes reports of security vulnerabilities in all its dependencies, including in the bundled JVM, and will issue an Elastic Security Advisory if such an advisory is needed.
Your vulnerability assessment must account for this to avoid an excess of spurious false-positive reports.
Yes, you should expect to upgrade to pick up security fixes and other improvements as needed. In rare cases it may be possible to find a workaround for a vulnerability without upgrading, but most of the time an upgrade will be the only mitigation and even if workarounds are available an upgrade will still be what we recommend.
Er, how is this different from any other java application?
You mention 8.13.2 (released Apr 5 2024) and 8.15.2 (released Sep 26 2024), 6 months between those releases. It's now April 2025, 6 months after release of 8.15.2.
It's a policy decision what drives, and under which circumstances, you perform your upgrades. Though true, the "there have been 18 releases since 8.15.2" point does not mean you should/must/would have used any of these, that's up to you. But ...
Well, on assumption that is "recent" upgrade, why did you recently choose to upgrade to 6-months-old 8.15.2? The bundled openjdk version was, well, bundled, so you could have easily have checked what version it was before doing the upgrade?
We have a 3-node cluster and Elasticsearch is running on all nodes for high availability. However, the OpenJDK vulnerability is reported on 'node 2' only (I'm not sure why, since all nodes have the same OpenJDK version i.e. 22.0.1).
This vulnerability was first observed in November 2024, which led us to perform an upgrade from 8.13.2 to 8.15.2 in December 2024.
We do not want to upgrade to the latest version of ELK (currently 9.0.0) as we are concerned it may be unstable.
As suggested by @DavidTurner, we are now planning to upgrade to 8.18.0.
I hope the upgraded version of OpenJDK (i.e. a version greater than 22.0.1) will be included in the 8.18.0 release.
After the upgrade, we will rescan the servers to verify whether the vulnerability is resolved.
I'd look into the security scanning as at first glance that result doesn't make much sense, so personally I'd want to understand that too.
Another personal view - I don't think there'll be much difference between 8.18.0 and 9.0.0. But you do have to go to 8.18.0 first (unless you are at 8.17.1+) to get to 9.0.0 anyways.
Both 8.18.0 and 9.0.0 bundle openjdk 24.
# pwd
/usr/share/elasticsearch/jdk
# bin/java -version
openjdk version "24" 2025-03-18
OpenJDK Runtime Environment (build 24+36-3646)
OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing)
I also don't mean to be rude, but IMHO you should "hope less, check more". This is pretty basic stuff to determine.
There's quite a lot of breaking changes in the release notes not to mention other stuff that landed in 9.x but hasn't been backported to 8.x.
I know you said you didn't mean to be rude but this was pretty rude @RainTown. It is not obvious how to check the JDK version bundled with each version, and downloading each 300MiB+ release just to look at the JDK version is not exactly user-friendly.
You can determine the JDK version for each release by looking at the source here:
Adjust the v8.18.0 in the URL to refer to other versions as you see fit.
Thanks for direct feedback @DavidTurner, which is noted.
I stand by what I wrote, good system administration should involve less hoping. IMHO. You disagree, fine. I actually shared the command to show the JVM version, in case the OP didn't know. It's also logged at elasticsearch startup, surely several other places, obviously in GitHub too.
You can disagree with and/or correct anything I write, obviously, no problem with that and I respect your opinion and appreciate your comments. People can consider the entire thread, and make up their own minds.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.