Oracle Java SE: Trust in compromised eMudhra CA certificates in JSSE

Summary

Oracle Java SE, Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition keep trusting eight compromised eMudhra intermediate CA certificates, plus eight certificates cross-signed by Sectigo, in the JSSE component. The JDK accepts these certificates in TLS connections and when verifying signed JAR files. An attacker holding the compromised keys can present certificates that Java treats as valid. The attack needs only network access and no authentication, and Oracle rates it as easily exploitable. No confirmed exploitation has been found.

Affected

• Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1
• Oracle GraalVM for JDK: 17.0.21, 21.0.13
• Oracle GraalVM Enterprise Edition: 21.3.20

Fixed in

Unknown. Oracle's alert recommends updating to the latest Java version or applying the recommended mitigations. The exact patched version numbers are not verified and must be confirmed in Oracle's Java SE Patch Availability Document. Third-party build numbers are unconfirmed, and one source states that OpenJDK fixes were still pending.

Workaround

• Replace the local blocked.certs file with Oracle's updated version. On Java 8 the file is named blacklisted.certs. Back up custom entries first.
• Enable revocation checking for TLS applications. On JDK 17 and later, enable revocation checks when verifying signed JARs.
• Do not rely only on removing the emSign root from cacerts, because the Sectigo cross-signed path may still be trusted.
• Fingerprint blocklists can be bypassed with re-encoded intermediates. Use them only as an interim measure.
• On Debian and Ubuntu, the Java keystore is not refreshed by OS trust-store updates alone. Recreate the keystore after the update.

Exploitation

• Oracle does not state that the vulnerability is exploited.
• Not listed in the CISA KEV catalog as of 22 October 2026.
• No public proof of concept or sufficient technical instructions was available at publication.
• No confirmed in-the-wild exploitation has been found. The private keys of the affected intermediates were publicly recoverable, so the risk is real.

Our recommendation

• Update all affected Java SE, GraalVM for JDK and GraalVM Enterprise Edition installations to the version listed in Oracle's Patch Availability Document, and confirm the exact fixed version before rollout.
• If patching is not possible immediately, apply Oracle's updated blocked.certs file and enable revocation checking.
• Inventory all Java runtimes, including embedded and vendor-packaged ones, and check the Java keystores on servers and clients.
• Monitor for unusual TLS or signed-JAR trust decisions and review the logs of internet-facing Java services.

Public exploits iAttack code is publicly available (PoC on GitHub, Metasploit or Exploit-DB).

Links to third-party sites, not checked by us – exploit code can contain malware. Only use it in isolated test environments.

• Proof of concept on GitHub (4 repositories) iAttack code is publicly available (PoC on GitHub, Metasploit or Exploit-DB).
  Carl0gonzalez/java-security-update · hubly12/javafix · FahrihFatahilah/CVE-2026-91403-eMudhra-Java-Scanner · siladu/fix-cve-2026-91403

Research sources

• Oracle Security Alert CVE-2026-91403 www.oracle.com
• Brandefense: CVE-2026-91403 brandefense.io
• Azul: eMudhra workaround docs.azul.com
• Beaconlab: Alert 2026-121 Oracle Java SE and GraalVM beaconlab.us
• SecurityOnline: Oracle Java security alert eMudhra securityonline.info
• Sonatype: Limits of fingerprint blocklists www.sonatype.com

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 31 Oct 2026, 05:33.