Java's emergency eMudhra fix (CVE-2026-91403) — which JDK build to install, vendor by vendor

Key takeaways

• Java needed its own fix for the eMudhra key compromise. Browsers blocked the eight weak eMudhra intermediates on 17–20 October, but a Java app uses the JDK's cacerts and blocked.certs, not the browser. Oracle published a Security Alert for CVE-2026-91403 (CVSS 9.1) on 21 October (Oracle alert, Cybersecurity News).
• The regular October CPU builds are not enough. The 20 October Critical Patch Update (55 Java SE fixes, 49 remotely exploitable without login, per Tenable) shipped 21.0.13, 17.0.21 and so on. Those exact versions are listed as affected. The fixes are re-spun .0.2 builds, for example 21.0.13.0.2.
• Vendor status differs. Oracle and Azul shipped fixed builds on 21 October. As of 23 October, Temurin, Corretto and Microsoft had no eMudhra statement, and Red Hat's fix comes through the OS ca-certificates package (Safeguard vendor tracker, Red Hat RHSB-2026-012).
• Don't trust the version number, check the file. A fixed build's lib/security/blocked.certs contains the eMudhra hashes. One independent test saw the file grow from 39 to 87 lines (lilting.ch test).
• No exploitation has been reported. The risk is a man-in-the-middle presenting a forged certificate to a Java client. Server-to-server API calls from Indian back-ends are exactly that kind of client.

1. Why Java is a separate problem

When we covered the eMudhra CA key compromise on 23 October, the urgent part was for browsers and website owners. Java works differently. A Spring Boot service calling a payment gateway, a Tomcat app hitting a GST or bank API, or a Jenkins agent pulling artifacts all decide trust from the JDK itself. Some JDKs bundle their own cacerts, while distro builds read the OS store.

The weak keys belong to eight eMudhra intermediates: six TLS and two code-signing. They chain to emSign ECC Root CA - G3, and Sectigo's AAA Certificate Services root cross-signed the same keys. Anyone who recovers a key can mint a certificate for any hostname that an unpatched Java client will accept. Red Hat tracks it as four CVEs: one each for Java, Go, Perl's Mozilla::CA and RHEL ca-certificates.

The test results are clear. On an unpatched OpenJDK 27.0.1, connections to test hosts signed by the compromised chain succeeded with HTTP 200. On the fixed 27.0.1.0.2 build they were rejected as untrusted (lilting.ch).

2. Fixed builds by vendor (status as of 23–25 October)

Treat the Temurin and Corretto rows as "unknown", not "safe". Those vendors may ship respins after this article, so check their pages. Whatever the version label says, the verification step in section 4 is what counts.

3. Three ways to fix it, compared

For most teams the answer is: update ca-certificates on distro JDKs, and either upgrade or drop in the new blocked.certs on bundled JDKs. Red Hat's interim advice for RHEL is blunter: blocklist the two roots entirely. Do that only if nothing you call depends on them.

4. How to check a JVM in two minutes

On each host or image:

1. Find the JDK actually in use. Run java -XshowSettings:properties -version 2>&1 | grep -E 'java.home|java.vendor|java.runtime.version'. Apps often ship their own JRE, so check the app's start script as well as PATH.
2. Count the blocklist. Run wc -l "$JAVA_HOME/lib/security/blocked.certs" (on JDK 8 the file is jre/lib/security/blacklisted.certs). Compare it with a known fixed build of the same vendor. A short, unchanged file means you are not patched.
3. See which roots you trust. Run keytool -list -cacerts -storepass changeit | grep -i -E 'emsign|comodoaaa'.
4. Check signed JARs if you verify signatures. On JDK 17+, jarsigner -verify -revcheck -strict app.jar turns on revocation checks for the two code-signing intermediates.
5. Rebuild containers. Base images like eclipse-temurin, amazoncorretto and UBI OpenJDK only pick up the fix when the image is rebuilt and redeployed. A running pod keeps the old trust store.

5. The India angle

Java runs much of India's enterprise back-office: bank core and middleware systems, insurance policy platforms, ERP add-ons, and the many Spring services that call bank, GST and payment-aggregator APIs. Many of these still run JDK 8 or 11 inside vendor-supplied application servers, where the bundled JRE gets missed. Ask your software vendor for their CVE-2026-91403 status in writing.

Two more points matter here. eMudhra is an Indian CA, so certificates from the affected hierarchy are more likely to show up in Indian deployments than elsewhere, even though eMudhra says none of the eight intermediates issued end-entity certificates. And CERT-In has already issued advisory CIAD-2026-0050 on the incident, so auditors will expect a dated record of when each system was checked.

On cost, the free OpenJDK builds (Temurin, Corretto, Microsoft, Zulu Community) cost ₹0 in licences. Paid support (Oracle Java SE subscription, Azul, Red Hat) buys faster respins, which this week was the real difference: Oracle and Azul had fixed builds within a day.

6. What to do this week

1. Inventory every JVM: servers, containers, CI agents, desktop tools, and vendor appliances with embedded Java.
2. Patch the trust store first: OS ca-certificates for distro JDKs, and a fixed build or the new blocked.certs everywhere else.
3. Rebuild and redeploy images. Don't stop at changing the Dockerfile tag.
4. Verify with the file check from section 4, and record the date per system for audit.
5. Still apply the regular October CPU. It fixes 55 other Java SE issues unrelated to eMudhra.
6. Watch Temurin and Corretto. If a respin lands, schedule it. If not, the blocked.certs drop-in stays your fix.

Need help inventorying and patching Java across servers and containers? That is part of our managed IT services. To check which CA issued your own site's certificate, use the free uptime & SSL checker.