Oracle Java drops four root certificates over eMudhra: patch, then test what breaks

Oracle has put out a second emergency Java update in four days over the eMudhra certificate keys. The October 24 builds take four root certificates out of Java's trust store, so update Java this week and test every outside HTTPS connection before you roll it out.

With a forged certificate, someone can sit in the middle of a connection and neither end notices. Your Java service thinks it's talking to the bank, the payroll provider or the identity server, so it hands over data and tokens. Oracle's 9.1 score for CVE-2026-114820 reflects that the attacker doesn't need a login or anyone's help. They do need to get onto the network path first, through a hostile Wi-Fi network, a poisoned DNS answer or a compromised proxy.

Nobody has reported an attack using these keys yet. Google says no website certificate chaining to the six TLS intermediates was logged to Certificate TransparencydefinitionPublic logs of issued certificates. Browsers require them, so a hidden forged certificate stands out. Java doesn't check these logs. before Chrome blocked them. India's CERT-In said on October 21 that the public disclosures don't establish confirmed malicious use. eMudhra says only one of the eight intermediates was ever used in production, and none had issued any end-entity certificate.

That's good news for browsers and weak comfort for Java. Certificate Transparency only catches certificates someone chose to log, and Java doesn't check the logs at all. The keys are also trivial to get now: Scott Helme reports recovering all eight from the public certificates in under a second, and researchers have published them. Anyone who wants to forge a certificate can, so the only thing protecting a Java build from before October 21 is that nobody has sat in the middle of its traffic yet.

For engineers: the eight intermediates are six TLS issuers (DV, OV and EV, each in G3B and G3C versions) and two code-signing issuers, and each one also exists as a copy cross-signeddefinitionA copy of an intermediate signed by a second root, so it's trusted by clients that only know that second root. Sectigo cross-signed the eMudhra intermediates under AAA Certificate Services. by Sectigo. The eMudhra copies chain to emSign ECC Root CA - G3. The cross-signed copies chain to AAA Certificate Services, an old Comodo root that Sectigo now owns. That second path is why removing the emSign root alone was never enough. A JVM that deleted only the emsigneccrootcag3 alias still trusted the six cross-signed TLS chains through comodoaaaca, a trap the Java developer Guillaume Laforge spelled out on October 21.

Oracle handled this in two Security Alerts. The first, CVE-2026-91403 on October 21, added the 16 bad certificates to Java's block list file, blocked.certsdefinitionA file in the JDK's lib/security folder listing certificates Java must never trust, even inside a chain to a trusted root. Java 8 calls it blacklisted.certs.. Oracle's release note says a TLS session won't be set up if the server's chain contains one of them, and a signed JAR fails jarsigner -verify -strict if it was signed through one. We covered that alert alongside the October Critical Patch Update.

The second, CVE-2026-114820 on October 24, takes the roots out as well. Oracle doesn't say in the alert why the block list wasn't enough. The practical effect is that nothing issued under these four roots is trusted any more, whatever it is, so the update closes the door on the compromised keys and also on every legitimate certificate from those hierarchies.

The table lists only the newest affected builds, because those are the ones Oracle names. Oracle only tests versions under Premier or Extended Support, and it says earlier releases are likely affected as well. If you're still on a Java line Oracle no longer supports, this is one more reason to move.

Start with the inventory, because it's usually where the time goes. Java turns up in places nobody lists as Java: a monitoring agent, a backup tool, the runtime that came bundled with a vendor product. Each of those has its own cacerts file, and none of them picks up the new list until that specific runtime is updated.

# example output, one runtime at a time
$ java -version 2>&1 | head -1
java version "21.0.13.0.3" 2026-10-24 LTS
# Java 11+: any of the four roots left?
$ keytool -list -cacerts | grep -iE 'emsign|aaa'
# no output: the roots are gone
# Java 8: point -keystore at jre/lib/security
# custom truststores the JDK update skips
$ ps -ef | grep -o 'trustStore=[^ ]*' | sort -u

A clean keytool result tells you the roots are gone. It doesn't prove the client rejects a bad chain. The researchers behind the disclosure run test hosts under emudhra.we-have-a-problem.com that serve chains through the compromised intermediates, including the cross-signed ones. If a Java client can still connect to them from the place it actually runs, it isn't protected yet.

This won't be the last time a certificate authority fails. Chrome and Firefox had the bad certificates blocked within hours of the report. Java's first fix came four days later and its second three days after that, and every container image and bundled runtime is still on its own timetable. The work that shortens that gap is mostly about knowing where your trust stores are and being able to change them quickly.

Revocation checking deserves a closer look than it usually gets. Java leaves it off by default, which is why a revoked certificate can still work against a Java client. Oracle's interim advice after the first alert was to turn it on with -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true. It adds a network lookup to handshakes and fails differently when the revocation server can't be reached, so test it on one service before you make it the default.

These three are made up, and none of them is a real incident or a Cohash client. They all install the same Java update. Where it hurts depends on choices made long before, like whose certificate a partner bought or who rebuilds the images.

We support Oracle E-Business Suite, PeopleSoft and Oracle identity estates, including their patch cycles and regression testing. For this alert we'd start with the Java inventory and the list of outside hosts, test the October 24 build against them, then roll it out without surprises at month end. See our Oracle EBS and Fusion ERP page, our PeopleSoft page and our Oracle identity page. For engineers to help with a patch window, see who we can staff. To find out first where your estate is exposed, start with an assessment.