JDK 8 Update 511 - Not Every Build Fixes eMudhra

After applying the October Holistic Patch on the OMS, a vulnerability scan still reports CVE-2026-91403 and CVE-2026-114820 for JDK 1.8.0_511. The Holistic Patch is applied, the JDK version is up-to-date - and the finding stays. I was looking at this for a while until I found the reason.

Oracle updated the My Oracle Support note EM 13.5/24ai: How To Remediate CVE-2026-91403 And CVE-2026-114820 (KB935075) and released a second build of JDK 8 Update 511. Both builds carry the same version number - only the build number and the patch number are different:

You need patch 40199083 to fix the eMudhra issue.

EM24ai Holistic October 2026

Since October 26, the second edition for Holistic Patch for Oracle Management Service October 2026 is available. It contains the JDK fix for ORACLE_HOME/common/jdk and delivers build b34.

You can apply patch 40207312 and the eMudhra issue for OMS is fixed. When already applied 40129968: use JDK exchange procedure.

The Vulnerability - Why Should I Care?

From the Oracle Security Alert: CVE-2026-91403 and CVE-2026-114820 are addressed by providing Java updates which distrust the set of impacted intermediate CA certificates related to eMudhra.

In short: the Java truststore (cacerts) of the JDK contains intermediate CA certificates which should not be trusted anymore. As long as they are in the truststore, Java accepts every certificate chaining to them - TLS connections, signed code, signed JARs. The fix is not a code change, the fix is to remove the distrusted CAs from the JDK.

Why this is important for Enterprise Manager:

• The OMS runs on Java. The Agents on every monitored host run on Java. OEM connects to targets, to My Oracle Support, to the Software Library and to your own integrations - all of them by TLS and all of them using the JDK truststore.
• OEM is the central management point for your database landscape. It stores credentials and can execute jobs on every host with an Agent. A weakness in trust handling for this system is not a minor finding.
• A vulnerability scanner reports the finding on every host with the affected JDK - OMS host and all Agent hosts. Fixing only the OMS is not enough.

I did not verify the CVSS scores in this post - read the Oracle Security Alert and the NVD entries for your own risk assessment.

Downtime - Minimal

The good news: no Release Update, no OMSPatcher run, no 90-minute deploy phase. The fix is a JDK replacement. Download the new JDK, put it in place of the existing JDK for the OMS and for each Agent, restart. Plan a short maintenance window for the OMS restart and a quick Agent restart per host - the downtime is minimal.

Documents

• My Oracle Support KB935075 - EM 13.5/24ai: How To Remediate CVE-2026-91403 And CVE-2026-114820
• Oracle Security Alert for CVE-2026-91403 and CVE-2026-114820 (link from the MOS note)
• Patch 40199083 - Oracle JDK 8 Update 511 b34
• Patch 40186682 - Oracle JDK 8 Update 511 - do not use, eMudhra is still in the truststore

The Setup

• Oracle Enterprise Manager 24ai, October 2026 Holistic Patch applied
• Oracle Linux Server Release 9.x
• JDK patch file stage directory is /tmp/jdktest - for this test only, the JDK is not installed yet
• All commands executed as OS user oracle

Read the patch readme first and ensure, you download the patch according to your platform (Windows, ARM etc.).

This is a quick check to verify cacerts file

Step 1 - Extract the Patch

Patch file is in the stage directory.

$ cd /tmp/jdktest
$ ll
total 295900
drwxr-xr-x   2 oracle oinstall        48 Oct 27 17:38 .
drwxrwxrwt. 38 root   root          8192 Oct 27 17:37 ..
-rwxr-xr-x   1 oracle oinstall 302985228 Oct 27 17:38 p40199083_180_511_Linux-x86-64.zip

Unzip the patch. The zip contains RPM and tar.gz, I use the tar.gz.

$ unzip p40199083_180_511_Linux-x86-64.zip

Archive:  p40199083_180_511_Linux-x86-64.zip
 inflating: jdk-8u511-linux-x64.rpm
 inflating: jdk-8u511-linux-x64.tar.gz
 inflating: MD5_VALUES
 inflating: readme.txt
 inflating: SHA256_VALUES

Extract the JDK - output is redacted for better readability.

$ tar xvfz jdk-8u511-linux-x64.tar.gz

jdk1.8.0_511/COPYRIGHT
jdk1.8.0_511/LICENSE
jdk1.8.0_511/README.html
jdk1.8.0_511/THIRDPARTYLICENSEREADME-JAVAFX.txt
jdk1.8.0_511/THIRDPARTYLICENSEREADME.txt
jdk1.8.0_511/bin/appletviewer
jdk1.8.0_511/bin/jar
jdk1.8.0_511/bin/extcheck
jdk1.8.0_511/bin/idlj
jdk1.8.0_511/bin/javadoc
jdk1.8.0_511/bin/javac
jdk1.8.0_511/bin/jarsigner
<REDACTED>
<REDACTED>

Step 2 - Test Java

Set JAVA_HOME to the extracted JDK and check the version. The important part is the build number: b34.

$ export JAVA_HOME=/tmp/jdktest/jdk1.8.0_511
$ $JAVA_HOME/bin/java -version

java version "1.8.0_511"
Java(TM) SE Runtime Environment (build 1.8.0_511-b34)
Java HotSpot(TM) 64-Bit Server VM (build 25.511-b34, mixed mode)

Step 3 - Verify eMudhra Is Removed

Set the path to the truststore of the new JDK.

$ CA=$JAVA_HOME/jre/lib/security/cacerts
$ echo $CA
/tmp/jdktest/jdk1.8.0_511/jre/lib/security/cacerts

Count the entries in the truststore.

$ $JAVA_HOME/bin/keytool -list -keystore "$CA" -storepass changeit | grep -E 'Your keystore contains'
Your keystore contains 107 entries

Former version contained 111 entries. Search for eMudhra and emSign certificates. No output means the distrusted CAs are removed.

$ $JAVA_HOME/bin/keytool -list -v -keystore "$CA" -storepass changeit | grep -E '^(Alias name:|Owner:|Valid from:)|SHA256:' | grep -iE -B1 -A2 'Owner:.*(emsign|emudhra)'
$

Run the same check against the JDK currently used by your OMS and Agents - if you get a hit, the host is affected.

Replace the JDK for OMS and Agent

Follow the steps in KB935075 to replace the existing JDK for the OMS and for each Agent with the new build. The principle is the same for both:

1. Stop the OMS / Agent
2. Put the new JDK in place of the existing JDK, follow MOS note EM 13.5/24ai: How To Remediate CVE-2026-91403 And CVE-2026-114820 In Enterprise Manager For OMS And Agent - KB935075
3. Start the OMS / Agent and verify the status
4. Run the keytool check from Step 3 against the JDK in use

Do OMS first, then roll out to the agents hosts. Using Agent Gold Images after the first Agent is done keeps the fleet consistent - see my previous post about the Agent patches.

And do not forget, Release Update 14 (24ai), Holistic October 2026 and the Agent FMW patches ist a must!

Summary

JDK 8 Update 511 exists in two builds with the same version number. Only patch 40199083 (b34) removes the eMudhra intermediate CAs and fixes CVE-2026-91403 and CVE-2026-114820. Patch 40186682 from last Thursday does not. The check is simple: java -version must show b34, and keytool must not list eMudhra or emSign in cacerts.

No Release Update, no OMSPatcher, just a JDK swap on OMS and Agent hosts - the downtime is minimal.

Check your JDK build. Patch your EM 24ai setup now!