Oracle Java CVE-2026-114820: eMudhra Root CAs Pulled From the JDK Trust Store

Oracle broke its quarterly schedule tonight to ship a single Java patch. CVE-2026-114820, published to the NVD at 19:17 UTC on 24 October 2026, is not a code bug in the JVM — it is a trust-store problem. Every supported Oracle JDK still ships the eMudhra root CA certificates in its default cacerts store, and eight of eMudhra's intermediate CA private keys were generated so badly that a researcher recomputed all of them from the public certificates in under a second. Oracle's out-of-band Security Alert removes those roots from Java's trust store. Until you apply it, your JDKs will accept a TLS certificate signed with a key anyone can forge.

Developing story — first published 23:43 CEST (21:43 UTC), 24 October 2026. Updated as Oracle and CISA publish more.

At a glance

CVE	CVE-2026-114820
Product / affected versions	Oracle Java SE 8u511 · 11.0.33 · 17.0.21 · 21.0.13 · 25.0.5 · 27.0.1 and earlier; Oracle GraalVM for JDK 17.0.21 & 21.0.13; GraalVM Enterprise Edition 21.3 — any build whose cacerts still trusts the eMudhra roots
Fixed in	Oracle out-of-band Security Alert of 2026-10-24 (Java updates that remove the eMudhra roots from cacerts); apply the latest build for your release train per Oracle's Patch Availability Document
CVSS	9.1 Critical · CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N · scored by Oracle (Secondary); NVD has no Primary score
Exploited in the wild	No — CISA SSVC exploitation: none as of 2026-10-24; Google found no fraudulent certificates in Certificate Transparency logs
CISA KEV	Not listed (catalog version 2026.10.23)
Public PoC	None public as of 2026-10-24; the underlying weak-key recovery is trivial — a researcher recovered all eight private keys on a laptop in under a second
Official advisory	Oracle Security Alert — CVE-2026-114820

What happened

In an April 2025 key-generation ceremony, eMudhra — an Indian certificate authority whose roots sit in the Mozilla, Microsoft, Apple and Chrome programs — produced a weak second set of private keys for eight intermediate CAs. The weak keys, not the intended strong ones, ended up in the certificates. On 17 October 2026 a researcher reported signed proof of control over all eight keys to the root programs (eMudhra incident site, maintained by Dennis Jackson). The Next Web reported that one private key simply evaluated to the integer 4, where a proper key of that type is a random 384-bit number; Scott Helme recovered all eight in under a second.

Browsers moved within hours. Google blocked the affected CAs in Chrome via a CRLSet keyed on their public-key hashes on 17 October, with no browser update required, and confirmed that because no certificates chaining to these intermediates were ever logged to Certificate Transparency, none could have been used against CT-enforcing clients (Google Security blog, 20 October). Apple blocked on 19 October, Microsoft on 20 October.

The browsers are the easy part. The long tail is every TLS client that carries its own trust store and does not enforce Certificate Transparency: language runtimes, container images, and the JVM. We covered the Python, pip and certifi side in a companion write-up. Oracle's alert is the Java chapter of the same story — and it is why CVE-2026-114820 carries CWE-327 ("use of a broken or risky cryptographic algorithm") rather than a memory-safety class: the algorithm is fine, the keys trusting it are not.

Who is exposed — and how to check your JDKs

The exposure is any application that uses the JDK's default cacerts to validate a TLS connection and does not pin certificates or enforce CT. That is the common case: HTTP clients, JDBC/TLS database drivers, message brokers, outbound webhook callers, and any service built on javax.net.ssl / JSSE with the stock trust store.

The attack is not remote-code-execution and it is not drive-by. It requires an attacker to (a) hold one of the recomputed eMudhra keys — trivial — and (b) sit on the network path between your JDK and the host it is talking to, then present a forged certificate. That makes the realistic target a CI runner on a shared segment, a build server reaching an internal registry, or a workload on a network an attacker already has a foothold in — not a well-NAT'd laptop at home. The CVSS vector reflects this: confidentiality and integrity high (read and rewrite TLS-protected data), availability none.

Find the roots before you decide how urgent this is. On each JDK:

# List any eMudhra / emSign roots still trusted by this JDK's cacerts
keytool -list -cacerts -storepass changeit 2>/dev/null | grep -i -A1 emsign
# Older/explicit form if -cacerts is unavailable:
keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit | grep -i emsign

An empty result means that JDK is either already patched or shipped without the roots. Any emsign… alias (for example emsignrootcag1, emsigneccrootcag3) means that runtime will trust a forged chain until you act.

Remediation

1. Am I affected? Run the keytool -list … | grep -i emsign check above on every JRE/JDK in the estate — not just the ones you install deliberately. Bundled runtimes inside application servers, vendor appliances, Docker base images and jlink-built custom runtimes each carry their own cacerts.

2. Patch — the exact fix. Apply Oracle's out-of-band Security Alert update of 24 October 2026: move each release train to the build that removes the eMudhra roots (Java SE 8, 11, 17, 21, 25, 27; GraalVM for JDK 17 & 21; GraalVM Enterprise Edition 21.3), per the Patch Availability Document linked from the alert. OpenJDK distributions (Temurin, Zulu, Corretto, Liberica, Microsoft) ship the same removal on their own cadence — check your vendor's October 2026 note and update the runtime, not just the OS.

3. Can't patch now? — remove the roots by hand. The fix is a trust-store deletion, so you can do it immediately without waiting for a full runtime upgrade:

# Delete each eMudhra/emSign root the list check found, e.g.:
keytool -delete -alias emsignrootcag1    -cacerts -storepass changeit
keytool -delete -alias emsigneccrootcag3 -cacerts -storepass changeit

Do this in your image build, not only on running hosts, or the next container redeploy reintroduces the roots. For a jlink runtime, rebuild it from a patched JDK. If an application overrides the default store with its own -Djavax.net.ssl.trustStore, fix that file too — the JDK patch does not touch custom trust stores.

4. Hunt for compromise. There are no attacker IOCs to chase here — nothing has been observed in the wild. The useful hunt is the inverse: query your Certificate Transparency monitoring and TLS inspection for any certificate chaining to an eMudhra/emSign intermediate presented to your clients, and review proxy and JSSE debug logs (-Djavax.net.debug=ssl:handshake) on high-value egress paths for unexpected issuer chains. Map to MITRE ATT&CK T1557 (Adversary-in-the-Middle) and T1588.004 (Obtain Capabilities: Digital Certificates).

5. Eradicate and verify. After patching or deleting, re-run the keytool -list … | grep -i emsign check and confirm it returns nothing on every runtime. Treat any host that terminated TLS through the compromised chain as needing credential rotation for anything that transited that connection.

What is not known yet

• Whether any of the recomputed keys were ever used to forge a certificate against a non-browser client. Google found nothing in CT logs, but CT does not cover clients that never check it — which is exactly the Java and Python population.
• The precise set of OpenJDK build numbers per distribution that carry the removal; vendors are publishing through the week.
• Whether CISA adds CVE-2026-114820 to the KEV catalog. As of catalog 2026.10.23 it is not listed, and the SSVC assessment records exploitation as none.

We will update this post as Oracle's Patch Availability Document, the OpenJDK vendor notes and any CISA action land.

Where this leaves you operationally

The hard question tonight is not "is there a patch" — there is — but "how many JDKs do we actually run, and which of them still trust these roots?" Most estates cannot answer that quickly, because runtimes hide inside appliances, images and application servers nobody inventories as "Java." This is the work an autonomous red team is built to do first: Zero Hunt's AI Remediation Advisor ranks the fix by real exploitability — not the raw CVSS 9.1 — and because nothing here is in KEV or exploited in the wild, it would place this below an actively-exploited edge CVE while still giving you the exact per-runtime action, the cacerts deletion as the compensating control, and a re-verification that runs the same trust-store check after the change rather than trusting a version string. Finding every runtime in the first place is a recon-and-validation problem the 10-agent swarm handles across the fleet, on an on-premise appliance, with a human approving anything that touches a production host.

If an attacker does take the network position this flaw needs, the forged TLS session is the only evidence — there is no log on the endpoint saying "a rogue certificate was accepted." That is the case Zero Hunt's AI Traffic Analysis was built for: a deep-learning model with four parallel inference heads, trained on billions of PCAP sequences and running locally on the appliance GPU, flags an anomalous TLS handshake to a never-seen destination or an unexpected issuer chain while the session is live — not in the next morning's SIEM digest, by which point the data has already been read.