Critical Java JSSE flaw CVE-2026-91403 trusts certs from compromised eMudhra CAs

Critical Java trust flaw accepts certificates from compromised CAs

On 21 October 2026 a critical vulnerability in Oracle Java SE's TLS trust handling was published as CVE-2026-91403, carrying a CVSS v3.1 base score of 9.1. According to an advisory posted on dev.to, the root cause sits outside Java itself: the private signing keys of eight intermediate certificate authorities run by eMudhra (emSign) were compromised. Sixteen certificates are implicated, spanning emSign and a Sectigo AAA cross-signing chain, and Java runtimes released before October 2026 still regard every one of them as trustworthy.

The flaw is filed under CWE-327, use of a broken or risky cryptographic algorithm, with a matching GitHub advisory, GHSA-9h75-rf66-wh3r. Its CVSS vector, network reachable with low attack complexity and no privileges or user interaction required, translates into severe confidentiality and integrity impact with no availability impact, consistent with silent interception rather than a crash. The report records a proof-of-concept as existing, an EPSS score of 0.38 percent, and no listing yet in CISA's Known Exploited Vulnerabilities catalogue.

How the bypass works

As the advisory explains, Java's Secure Socket Extension validates certificate chains against the bundled cacerts keystore, while a separate deny-list, blocked.certs on Java 11 and later and blacklisted.certs on Java 8, is meant to reject certificates known to be compromised. The catch is that Java leaves online revocation checking, OCSP and CRLs, switched off by default.

On builds that predate the October 2026 blocklist refresh, none of the 16 compromised intermediates appear in that deny-list, so nothing stands between a fraudulent certificate and a successful handshake. An unauthenticated attacker positioned between a Java client and its server can therefore read and alter encrypted traffic in transit, or defeat code-signature verification, and the application sees no error.

Affected versions

The report names Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition and OpenJDK as affected, together with downstream distributions such as Eclipse Temurin, Red Hat OpenJDK, Amazon Corretto and Azul Zulu.

Fixed Oracle Java SE builds are listed as 8u511 and later, the .0.2 revisions of 11.0.33, 17.0.21, 21.0.13 and 25.0.5, and 27.0.1. OpenJDK distributions are considered patched from 25.0.5+8 and the corresponding 21.0.13 and 17.0.21 builds that carry the updated blocklist, while GraalVM fixes are covered by Oracle's security alert for this CVE.

How to remediate

The advisory lays out several paths, from full upgrades to manual workarounds:

• Upgrade every Java installation to a patched build containing the refreshed blocked.certs database.
• Where an upgrade is not immediately possible, append the 16 SHA-256 fingerprints of the compromised intermediates to blocked.certs (or blacklisted.certs on Java 8).
• If deny-listing is not supported, remove the affected root aliases, emsigneccrootcag3, comodoaaaca, emsignrootcag1 and emsignrootcag2, from cacerts with the keytool utility.
• On Debian and Ubuntu hosts, and in container images that link the JVM keystore to the system trust store, update the ca-certificates package and regenerate the Java trust store under /etc/ssl/certs.
• Restart all running JVMs, application servers and containerised services so the updated trust material is loaded, then verify with Oracle's CheckCerts.java utility or one of the community scanners; a remediated runtime should reject chains anchored to the compromised intermediates with a ValidatorException.

Why it matters

This vulnerability is a reminder that certificate validation is only as strong as its revocation path. Because Java skips OCSP and CRL checks unless they are explicitly enabled, the blocklist is effectively the only mechanism that reacts to a CA compromise, and a missing entry converts a third-party breach into a transparent TLS bypass on every unpatched JVM. Java's footprint makes that surface enormous: application servers, build pipelines, containers and long-lived appliances all ship or embed their own cacerts, so patching the operating system alone does not close the gap. The modest EPSS score suggests opportunistic exploitation is not yet widespread, but for any organisation whose Java services carry sensitive traffic, inventorying runtimes and applying the blocklist update is the urgent action.