SUNNYVALE, Calif. — October 22, 2026 — Azul, the trusted leader in enterprise Java for today’s AI-first world, issued the following statement in response to the eMudhra Intermediate CA Certificates Compromise made public on October 20, 2026:
What Happened
On October 20, 2026, the compromise of eight eMudhra intermediate CA certificates became public. eMudhra reported, and Mozilla and Google’s Chrome Root Program confirmed that the affected private keys were generated defectively, so anyone can derive them from the public certificates and impersonate websites and services that trust the affected chain. eMudhra has revoked the certificates, and Apple, Google, Microsoft and Mozilla have blocked them in their browsers and operating systems. eMudhra has stated that only one of the eight intermediates was ever used in production and that none of them issued any end-entity certificate, and Google reported finding no certificates chaining to them in Certificate Transparency logs. Every component that decides which certificates to trust, including Java runtimes, has to react.
Why This Matters for Java
Java runtimes do not receive revocation data automatically and do not check certificate revocation by default. The compromised intermediates chain to roots that many OpenJDK distributions trust, so an unpatched JDK may accept a forged certificate signed with the compromised keys. Because so much of the world’s business and infrastructure software relies on the Java runtime (JVM/JDK) for the secure connection it makes, the fix has to be in the JDK itself. That fix is a block list (lib/security/blocked.certs) that can reach a runtime in one of two ways: in a JDK update, or as a file placed by hand into every installed runtime, including copies embedded in applications, container images and CI pipelines, followed by a restart. The first path runs through the update process most Java organizations already have. The second is a custom procedure assembled under pressure. Azul treated this as a critical time-sensitive issue and focused immediately on delivering the first path.
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, and Azul Prime (Azul Zing Builds of OpenJDK) for Java 25, 21, 17, 11 and 8. These updates block the eight compromised certificates, and no manual changes to the JDK are needed after installing. To maximize stability, Azul delivered the fix as part of a Security-only, Stability-first update™, which is built on the prior-cycle release with only security fixes, so it carries a lower risk of regression.
To update to the latest build, see the Azul Zulu release notes and the Azul Zing release notes for the October 21, 2026, out-of-cycle update.
FAQs
What should enterprises do when a certificate authority’s private keys are compromised?
Enterprises should confirm which software still trusts the compromised certificates, apply vendor updates that block them, and use temporary workarounds only where an update is not yet available. Browsers and operating systems receive revocation data automatically, but many other frameworks and runtimes do not check revocation, including Java by default. In the October 2026 eMudhra intermediate certificates compromise, Azul released updates to Azul Zulu Builds of OpenJDK that add the eight compromised certificates to the JDK’s blocked certificate list, with no manual workaround needed after upgrading.
Is a manual workaround or a full update better for a Java security issue?
A full, installable update is generally better because it applies through existing deployment processes and avoids hand-editing each Java Development Kit (JDK) installation, which is error-prone across large fleets. A manual workaround is appropriate only as a stopgap for runtimes that cannot be updated immediately. For the eMudhra certificates compromise, Azul published both: complete updates for Azul Zulu versions 27, 25, 21, 17, 11, 8, 7 and 6, and a documented workaround for runtimes that cannot be updated right away.
How quickly should our Java vendor patch a newly disclosed CVE?
Because the vast majority of disclosed JDK Common Vulnerabilities and Exposures (CVEs) are known to Java vendors that participate in the OpenJDK Vulnerability Group, Java vendors should be able to provide updates that address the CVEs immediately upon disclosure. Fast delivery matters because attackers can exploit disclosed flaws quickly. Azul released an update that addressed 53 newly disclosed CVEs immediately upon their disclosure on October 20, 2026. In addition, its out-of-cycle Azul Zulu updates were released on October 21, 2026, the day after Mozilla and Google’s Chrome Root Program publicly confirmed the eMudhra intermediate certificates compromise, and before any CVE had been assigned.
How do organizations ensure timely Java security patching without breaking production?
Timely patching without outages depends on being able to separate urgent security fixes from unrelated non-security changes. Security-only releases enable this separation and reduce the chance that an urgent patch introduces production-effecting regressions. Azul delivered its eMudhra certificate fix as a Security-only, Stability-first update™, which is built on the prior-cycle release and adds only security fixes, so customers can install it with a lower risk of regression.
About Azul
Azul is the trusted leader in enterprise Java for today’s AI-first world. Its open source-based Java platform empowers organizations to optimize the entire Java lifecycle to accelerate performance, strengthen security, reduce licensing and cloud costs, and boost developer productivity. Azul powers mission-critical systems for 37% of the Fortune 100, 50% of the Forbes Top 10 World’s Most Valuable Brands, and the world’s top 10 financial trading companies. Learn more at azul.com and follow @azulsystems.
# # #
Media Contact for Azul:
Treble
Josh Georgiou
[email protected]