Serguey Asael Shinder: OpenJDK: update Java or remove four roots after the eMudhra key compromise
The OpenJDK Vulnerability Group has published guidance for everyone running a standalone Java runtime after the private keys of eight intermediate certificate authorities belonging to eMudhra, an Indian CA, were found to be recoverable from their public certificates. The page asks users to act immediately, "even if you have updated your runtime in the past few days". (https://openjdk.org/emudhra)
The reason Java needs its own fix is that it does not check certificate revocation by default. Browsers and operating systems blocked the revoked intermediates quickly; a Java runtime keeps trusting anything that chains to a root in its own cacerts keystore. OpenJDK's advisory of 24 October lists CVE-2026-114820 in security-libs/java.security with a CVSS base score of 9.1, affecting 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.32.1, 8u504 and earlier. (https://openjdk.org/groups/vulnerability/advisories/2026-10-24)
The preferred fix is a vendor update whose release notes mention JDK-8395690 / CVE-2026-114820. Until one is available, the page gives keytool commands to back up the keystore and delete four roots — the three emSign roots and Comodo's AAA Certificate Services — then restart every running JVM. As a further alternative it describes enabling CRL checks with -Dcom.sun.security.enableCRLDP=true and verifying signed JARs with jarsigner -verify -revcheck.
Linux packaging matters here. On some distributions the JDK uses the operating system's certificate store and an OS update is likely enough; Debian-derived systems, including Ubuntu, keep a separate Java keystore that needs extra steps, and the FreeBSD and Homebrew packages do not use the system store at all.
Docker images are the case people miss: the Java inside an image does not change when the host's Java is updated. Ethereum's Teku client, for example, shipped new images this week for exactly that reason.