CVE-2026-114820 and CVE-2026-91403: Java eMudhra fixes, what to do

Java runtimes needed two emergency fixes in four days after the eMudhra certificate compromise. On 21 October the OpenJDK Vulnerability Group published CVE-2026-91403, a CVSS 9.1 flaw in the JDK's TLS code (security-libs/javax.net.ssl), and on 24 October it published a second entry, CVE-2026-114820, with the same score and component. If any of your services, build agents, containers or desktop apps run Java, the runtime they carry may still trust certificates that an attacker can forge. This article explains what each fix does, which builds are named, and how to check and protect a Java installation today.

Key points

• OpenJDK's advisories of 21 October (CVE-2026-91403) and 24 October (CVE-2026-114820) each rate the TLS flaw CVSS 3.1 base score 9.1, and list JDK 8, 11, 17, 21, 25 and 27 as affected.
• The cause is the compromise of eight eMudhra intermediate CA certificates, disclosed on 20 October: their private keys were generated defectively, so anyone can derive them from the public certificates.
• Oracle's alert for CVE-2026-91403 says its Java updates distrust the impacted intermediate certificates; its alert for CVE-2026-114820 says its updates remove the impacted root CA certificates.
• OpenJDK's advice is to install a vendor runtime whose release note documents the fix for JDK-8395690 / CVE-2026-114820, and to use a keystore workaround or revocation checking only where no update exists yet.
• The regular Oracle Critical Patch Update of the same week fixed 55 Java SE vulnerabilities, none rated above 7.5, so the two eMudhra entries carry higher scores than anything in that quarterly matrix.

What to do

Who is affected. Any application that uses a Java runtime to make or accept TLS connections or to verify signed JAR files, and whose runtime ships its own cacerts keystore. OpenJDK's advisories name JDK 8, 11, 17, 21, 25 and 27 (and earlier builds). Oracle's alerts cover Java SE 8, 11, 17, 21, 25 and 27 plus GraalVM for JDK 17 and 21. Runtimes that are no longer supported by their vendor are not tested, and Oracle says earlier releases are likely affected too.

1. Check your runtime. OpenJDK publishes a small program, CheckCerts.java, that works on JDK 8 and later and reports whether the runtime is at risk. Run it with each Java installation you have, including copies embedded in applications, container images and CI runners.

2. Update to a build that documents the fix. OpenJDK's guidance on its eMudhra page is to download an updated runtime from your vendor and confirm that its release note says it fixes issue JDK-8395690, CVE-2026-114820. This applies even if you updated a few days ago, because the first fix (CVE-2026-91403) was followed by the second.

3. If your vendor has no update yet, pick one workaround.

• Remove the relevant root certificates. Back up the keystore ($JDK_HOME/lib/security/cacerts for JDK 11 and later, $JDK_HOME/jre/lib/security/cacerts for JDK 8), then delete four aliases and restart the runtime: emsignrootcag1 [jdk], emsignrootcag2 [jdk], emsigneccrootcag3 [jdk] and comodoaaaca [jdk], for example keytool -delete -cacerts -alias "emsignrootcag1 [jdk]". Error messages saying a certificate does not exist can be ignored. Repeat for every installed runtime.
• Or turn on revocation checking for TLS by adding -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true to the application's java command line. For signed JAR files on JDK 17 and later, verify with jarsigner -verify -revcheck -strict <file.jar>.

4. Distribution packages. OpenJDK says Java packages in Arch Linux, Fedora, Gentoo, Oracle Linux and Red Hat Enterprise Linux most likely use the operating system's certificates, so updating the system's certificate bundle is likely enough. Debian and its derivatives (Devuan, Ubuntu) need a manual step because of a long-standing bug in ca-certificates-java: as the superuser, run rm -f /etc/ssl/certs/java/cacerts and then update-ca-certificates --fresh. FreeBSD and Homebrew packages do not use the system certificates; update the packages directly once new versions are available.

5. Do not switch verification off. Cloudflare's guidance on the same incident warns that once the fixes are applied you may see new certificate errors and that these should not be "fixed" by disabling verification, because that removes the protection the update restores.

What happened

The sequence, from the vendors' own pages:

• 19 October, about 17:00 UTC: Cloudflare says it became aware that the private keys of eight eMudhra intermediate certificates were compromised and began patching its own services before the public disclosure.
• 20 October: the compromise became public. eMudhra reported, and Mozilla and Google's Chrome Root Program confirmed, according to Azul's summary, that the keys were generated defectively and can be derived from the public certificates. The same day, OpenJDK published its regular quarterly advisory and Oracle its October Critical Patch Update.
• 21 October: OpenJDK published an out-of-cycle advisory for CVE-2026-91403 and Oracle published a Security Alert for it. Azul released updated Zulu builds the same day.
• 24 October: OpenJDK published another advisory, for CVE-2026-114820, and Oracle a second Security Alert.

The CVE entries describe the Java side of the incident rather than a new bug in Java's TLS code. In both advisories the component is security-libs/javax.net.ssl, the score is 9.1 and the vector string is NLNNUHHN, which in CVSS 3.1 terms means network attack, low complexity, no privileges, no user interaction, unchanged scope, high confidentiality and integrity impact and no availability impact. That fits the situation: an attacker holding a forged certificate chain that Java trusts could impersonate a server or a signer without touching the victim's machine first.

The eMudhra side matters for how worried to be. Azul's statement, which repeats what eMudhra reported, says only one of the eight intermediates was ever used in production and none of them issued an end-entity certificate, and that Google reported finding no certificates chaining to them in Certificate Transparency logs. Cloudflare says its review had not identified active exploitation on its services. None of this is evidence that nobody has used the keys: anyone can derive them, and a forged certificate would not need to appear in a public log to fool a client that trusts the chain.

Background

Browsers handle a compromise like this with centrally pushed revocation and distrust lists. Azul points out that Apple, Google, Microsoft and Mozilla have blocked the eight certificates in their browsers and operating systems. Java is different. Azul states that Java runtimes do not receive revocation data automatically and do not check certificate revocation by default, so the fix has to travel inside the JDK. The mechanism is a block list, lib/security/blocked.certs, which can arrive either in a JDK update or as a file placed by hand into each installed runtime followed by a restart. That is why OpenJDK's page leads with "update your runtime" and offers the keystore edits only as a stopgap.

We covered the incident itself when it broke, in eMudhra's eight compromised TLS intermediate certificates, and the general mechanics of trust and revocation in how TLS certificate trust and revocation work. The Java entries add the part that most affects server-side teams, because a server's JVM or a CI agent's JDK is exactly the kind of non-browser client that keeps trusting a chain after browsers have dropped it.

How the two fixes differ

Oracle's two Security Alerts describe different actions. The alert for CVE-2026-91403 says its Java updates "distrusts the set of impacted intermediate CA certificates related to eMudhra". The alert for CVE-2026-114820 says its updates remove "the set of impacted root CA certificates related to eMudhra". We read this as a second, broader step: the first update blocks the eight known-bad intermediates, and the second takes out the roots they chain to. The OpenJDK keystore workaround, which deletes four root aliases (three emsign roots and comodoaaaca), points the same way. Neither OpenJDK nor Oracle spells out in the pages we read why the second step was needed, so treat our explanation of the reason as an inference.

Version numbers need care. Oracle's alert for CVE-2026-91403 lists the affected products as Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1. Its alert for CVE-2026-114820 lists builds with a further suffix: 8u511-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2 and 27.0.1.0.2, and OpenJDK's 24 October advisory names the same .0.2 builds as affected. These are the lists of products "affected" by each alert, so they identify the builds that existed before each fix rather than the fixed ones. We could not find the fixed build numbers for the second fix on the pages we read. That is why the safest check is the vendor's release note, which should mention JDK-8395690 and CVE-2026-114820.

Vendor status when we checked on 25 October:

• Azul: Zulu builds for Java 27, 25, 21, 17, 11, 8, 7 and 6, and Azul Prime for Java 25, 21, 17, 11 and 8, released on 21 October as an out-of-cycle update that blocks the eight certificates; Azul says no manual change is needed after installing. Its statement is dated 22 October and describes the first fix; we did not see on its page whether a build for CVE-2026-114820 had shipped.
• Amazon Corretto: the Corretto 25, 21, 17, 11, 8 and 27 changelogs list CVE-2026-91403 (CVSS 9.1, security-libs/javax.net.ssl) among the fixes in the October releases (for example 25.0.5.0.9 and 21.0.13.0.10). We found no entry for CVE-2026-114820 in the changelogs we opened.
• Oracle: Security Alerts exist for both CVEs and say patches are provided only for versions under Premier or Extended Support.

The numbers

Oracle's regular October Critical Patch Update, published the same week, contains 1,295 new security patches across all its product families. We counted the Java SE risk matrix in Oracle's text version: it lists 55 CVEs, 49 of which Oracle describes as exploitable by an unauthenticated attacker over the network, and the highest base score is 7.5. By score band:

4.0 to 6.938

Below 4.014

7.0 to 8.93

Java SE vulnerabilities in Oracle's October 2026 CPU, by CVSS 3.1 base score (our count) (CVEs)

	CVEs
4.0 to 6.9	38
Below 4.0	14
7.0 to 8.9	3

Source: Oracle, Text Form of Oracle CPU October 2026 Risk Matrices (Java SE)

Against that background, the two 9.1 entries stand out. They are not in Oracle's CPU matrix; they come from the separate Security Alerts, and no CVE in the CPU's Java SE matrix is rated above 7.5. Note also that scores in Oracle's matrix and in the OpenJDK upstream risk matrix can differ for similar issues, so compare CVE IDs rather than assuming a single rating.

What it means

For operations teams. The inventory problem is the hard part. A JDK can live in a container base image, a build agent, an IDE, a vendor appliance or inside a desktop application that bundles its own runtime. OpenJDK's checker program is designed to be run per runtime, so the practical approach is to scan images and hosts for java binaries and run it against each, then rebuild images rather than patching in place.

For developers. If your tests or tools fail with certificate errors after an update, look at what the error names before touching trust settings. Cloudflare's advice is not to resolve these by disabling verification, and its developer note adds that updating an SDK may not change policy when certificate verification is delegated to an HTTP library, a language runtime or the operating system underneath.

For vendors and maintainers. The episode shows how slowly trust changes reach clients that do not check revocation. Browsers were protected within a day; a Java runtime is protected only when someone updates or edits it.

What we don't know yet

• Whether any forged certificate chaining to the eight intermediates has been used against a real target. The sources we read report no active exploitation on Cloudflare and no certificates in Certificate Transparency logs, but that is not proof for other environments.
• The exact fixed build numbers for CVE-2026-114820 at each vendor, and when Corretto and the Linux distributions will ship them.
• Why OpenJDK and Oracle split the response into two CVEs rather than one; the pages we read describe the actions but not the decision.

What to watch next

Vendor release notes that cite JDK-8395690 and CVE-2026-114820, an update to Corretto's changelogs, distribution advisories for Debian and Ubuntu, and the list of patched packages that Mozilla's Dennis Jackson has been crowdsourcing, which Cloudflare links from its post. OpenJDK also updates its eMudhra page as vendors ship.

Sources

• OpenJDK: Compromised Certificates and OpenJDK Java Runtimes
• OpenJDK Vulnerability Advisory, 2026/10/21 (CVE-2026-91403)
• OpenJDK Vulnerability Advisory, 2026/10/24 (CVE-2026-114820)
• OpenJDK Vulnerability Advisory, 2026/10/20
• Oracle Security Alert Advisory, CVE-2026-91403
• Oracle Security Alert Advisory, CVE-2026-114820
• Oracle Critical Patch Update Advisory, October 2026 and its text-form risk matrices
• Azul statement on the eMudhra intermediate CA certificates compromise
• Amazon Corretto 21 changelog and Corretto 25 changelog
• Cloudflare: 8 eMudhra certificates are compromised