Thought Leadership
Azul has issued the following statement regarding the compromise of eMudhra’s intermediate Certificate Authority (CA) certificates, which became public on October 20, 2026.
What Happened
On October 20, 2026, it became public that eight of eMudhra’s intermediate CA certificates had been compromised. According to eMudhra, with confirmation from Mozilla and Google’s Chrome Root Program, the affected private keys were generated incorrectly, making it possible to derive them from the corresponding public certificates. aThis means attackers could impersonate arbitrary websites or services to any system that trusts the affected certificate chains. eMudhra has revoked the certificates, and Apple, Google, Microsoft, and Mozilla have blocked them in their browsers and operating systems.
According to eMudhra, only one of the eight intermediate certificates had ever been used in production, and none had issued an end-entity certificate. Google also reported that it found no certificates in Certificate Transparency logs that chained to the affected intermediate certificates. All components that validate certificate trust must therefore respond to the incident, including Java runtimes.
Why Java Is Affected
Java runtimes do not automatically receive revocation data and do not check whether certificates have been revoked by default. The compromised intermediate certificates chain to root certificates trusted by many OpenJDK distributions. As a result, an unpatched JDK could accept a forged certificate signed with the compromised keys. Much of the world’s business and infrastructure software relies on the Java Virtual Machine (JVM) and Java Development Kit (JDK) to establish secure connections. The fix must therefore be implemented at the JDK level.
The fix consists of a blocklist (lib/security/blocked.certs) that can be deployed to a runtime environment in one of two ways: through a JDK update or by manually copying the file into every installed runtime environment. This includes copies embedded in applications, container images, and CI pipelines. A restart is then required. The first option uses the update process that most organizations running Java already have in place. The second requires a separate procedure to be established under time pressure. Azul classified the issue as critical and time-sensitive, immediately focusing on delivering the first option.
What Azul Has Done
Within 24 hours of the public disclosure, Azul published a documented workaround and released updated, tested Azul Zulu Builds of OpenJDK for Java 27, 25, 21, 17, 11, 8, 7, and 6, as well as Azul Prime (Azul Zing Builds of OpenJDK) for Java 25, 21, 17, 11, and 8. These updates block all eight compromised certificates. No manual changes to the JDK are required after installation. To maximize stability, Azul delivered the fix as part of a security-only, stability-first update. It builds on the previous release cycle and contains only security fixes, reducing the risk of regressions.
(Editorial Team/Azul)
