SURIQ
When a certificate authority's keys turn out to be weak enough to pull straight out of the public certificate, every mainstream browser distrusts it within hours. The trust store inside your Java runtime does not move that fast. That gap is what CVE-2026-114820 is really about: an out-of-band Oracle Security Alert, published on October 24, 2026, that finally removes a compromised certificate authority from Java after the rest of the internet had already thrown it out. Oracle rates the issue CVSS 9.1.
The trust store browsers patched and Java did not
Chrome, Firefox, Safari and Edge each run their own root program, and they pushed blocks for the compromised certificates between October 17 and 21. Operating-system vendors followed. But the Java Development Kit carries its own separate trust store, the cacerts keystore, and nothing in an operating-system or browser update touches it. A Java Virtual Machine reads cacerts to decide which certificate authorities to trust when it opens a TLS connection. Per the Endor Labs analysis of the incident, the correct assumption was to treat Java services as unconfirmed until the JDK vendor shipped its own update.
This is the same quiet failure mode we have tracked in a SAML signature-validation bypass in Keycloak and a certificate-trust bypass in OpenShift: the high-impact problems hide in trust decisions, not in exploitable code.
Why a recoverable CA key is a wiretap on your TLS
The root cause sits with eMudhra, an Indian certificate authority. On October 17, 2026 a researcher known as Wayne reported to the Mozilla and Chrome root programs that eight of eMudhra's intermediate certificates had been generated with so little randomness that their private keys were derivable directly from the public certificate. Security researcher Scott Helme said the recovered keys were trivial, with one of them simply the integer 4, and that the full set came off a laptop in seconds. Six of the eight could be used to impersonate any website, according to reporting by The Hacker News. The intermediates chained to roots in every major root program, both directly and through a Sectigo cross-signature.
eMudhra attributes the fault to a flawed key ceremony rather than negligence, and has stated that only one of the eight intermediates was deployed in production and that none of them issued end-entity certificates. India's CERT-In noted that the public disclosures do not establish confirmed malicious use of the keys, and no in-the-wild abuse has been reported. The company announced on October 22 that it is exiting the public TLS certificate business.
For a defender, the mechanism is what matters. Anyone holding a recovered key can mint a certificate that validates for any hostname. Present that forged certificate to a Java client that still trusts the authority, and the Java Secure Socket Extension (JSSE), the TLS layer inside the runtime, will accept it. Oracle scores CVE-2026-114820 at CVSS 9.1: reachable across the network, needing no authentication and no user interaction, with high impact to both confidentiality and integrity. That is the signature of a machine-in-the-middle attack on traffic your application assumed was encrypted end to end.
Who is exposed
Any Oracle Java SE or GraalVM deployment that opens or terminates TLS using the default cacerts and has not taken Oracle's October 24 update. Oracle's alert lists affected builds across Java SE 8, 11, 17, 21, 25 and 27, plus Oracle GraalVM for JDK 17 and 21 and GraalVM Enterprise Edition 21.3. The Oracle Security Alert ships updated builds that remove the affected eMudhra roots.
In practice this is server-side Java, the part of your stack no browser update reaches: application servers, build and continuous-integration tooling, search and messaging clusters, database drivers, and any agent that calls an external HTTPS endpoint. Those processes rarely have their trust store audited, and the OS patch cycle will not fix them. Of the 212 vulnerabilities we judged worth publishing in the last 90 days, nearly all were code you patch. This is the rarer kind, a trust decision frozen in a file, and it is exactly the sort an update manager steps over.
You can check a running JDK directly. The default cacerts password is changeit; any match means that Java still trusts the distrusted authority.
keytool -list -cacerts -storepass changeit | grep -i "emsign\|emudhra" # Windows PowerShell: pipe the list to findstr /i "emsign emudhra" keytool -delete -alias <alias-from-the-list> -cacerts -storepass changeit
Patch the JDK, then hunt the trust stores you forgot
Apply Oracle's October 24 Security Alert update for every Java train you run; it removes the affected roots for you. If you cannot patch a host immediately, run the check above and delete each eMudhra alias by hand, then plan the update. That closes the exposure on the servers a vulnerability-monitoring program should already be flagging.
Then widen the search. Every runtime that ships its own trust store is now suspect: Node.js, Python's certifi, Go, and the frozen root bundles inside individual packages all carry a list your operating-system patch never visits. Inventory them the same way.
The harder question is whether you would ever know. Patching removes the roots, but it tells you nothing about whether a forged certificate was presented to one of your Java clients during the months the weak keys were live. If you are not collecting and retaining TLS certificate-chain telemetry for sensitive outbound calls, there is no record to go back to. The defensible posture is to capture that handshake and certificate evidence before the next authority fails, not after. A CA that anyone can impersonate is not a once-a-decade event anymore, and the trust store that lags is the one on your servers.