Back

30/10/2026

Browsers Were Protected in Hours. What About Enterprise Java? How LOGIQ Responded to the eMudhra Certificate Incident

Browsers blocked the compromised eMudhra intermediates within hours, but every JDK carries its own trust store. What Azul and BellSoft shipped, what LOGIQ did, and what to check now.

Key takeaways

  • On October 17, 2026, Mozilla received a report that the private keys of eight eMudhra intermediate CA certificates had been compromised. Browsers blocked them within hours to days. eMudhra says it is not aware of any evidence that the keys were exploited.
  • Java does not use the browser’s or the operating system’s trust decisions. Every JDK, and every container image or application that bundles one, carries its own trust store. Each of them needs its own update.
  • Azul shipped two out-of-cycle Zulu updates, on October 21 and October 24. The second one exists because the first fix was not enough, so the October 21 workaround is no longer sufficient on its own.
  • BellSoft lists fixed Liberica builds for Java 8, 11, 17, 21, 25 and 27. LOGIQ obtained these builds through our BellSoft support channel and made them available to our customers.
  • What to do: find every Java runtime you run, check the exact vendor and build, move to that vendor’s fixed build, test your TLS connections, and keep watching for out-of-cycle releases.

What happened

On Saturday, October 17, 2026, at 20:06 UTC, Mozilla received a report that the private keys of eight eMudhra intermediate certificates had been compromised. Mozilla blocked the eight certificates in Firefox through OneCRL, its central revocation list, and the update had reached users with standard settings by 22:59 UTC, less than three hours later. Mozilla disclosed the incident publicly on October 20. It also shipped Firefox point releases for users whose settings blocked the OneCRL update, and it removed the root certificate that signed the intermediates from the NSS trust store.

The risk is certificate forgery. Anyone holding one of these keys could issue an HTTPS certificate for a site they do not control. If they could also get between a client and that site, they could impersonate it and read or change the traffic.

There is no evidence so far that this happened. In its incident statement, eMudhra says the eight intermediates were revoked on October 18, that none of them had issued any end-entity certificates, and that it is “not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed.” eMudhra describes the cause as weak keys generated during a 2025 key ceremony. It says it has not yet confirmed the exact root cause, and its investigation is ongoing. The browser root programs distrusted the eMudhra root above these intermediates as a precaution.

So this article is about closing a window of exposure, not about a confirmed attack.

Why Java needs its own fix

Browsers and operating systems have automatic ways to stop trusting a certificate authority, and they used them quickly. Azul’s account of the incident says Chrome blocked the certificates on the same day, Apple on October 19 and Microsoft on October 20.

Java does not inherit any of this. A JDK decides which certificates to trust from its own files:

  • Its own trust store. Every JDK ships its own cacerts file. Updating the operating system’s certificate bundle, or restarting a browser, does not change it.
  • No revocation checks by default. As Azul’s documentation puts it, Java trusts the root certificates these intermediates chain to and “doesn’t check revocation by default.” eMudhra revoking the intermediates does not, by itself, protect a Java client.
  • Many copies. A server can run the system JDK, a JDK bundled inside an application, a jlink runtime, and several container images, each with its own copy of the trust store. Each copy stays exposed until it is updated or rebuilt.

So a Java service that makes outbound TLS calls can still accept a forged certificate after every browser in the building is protected. That is the gap this article is about.

Two emergency updates from Azul

Azul released two out-of-cycle updates for Azul Zulu after its October quarterly release:

  • October 21: the first out-of-cycle update adds the eight compromised intermediates to the JDK’s block list (blocked.certs in JDK 11 and later, blacklisted.certs in older versions). It covers Zulu 27, 25, 21, 17, 11, 8, 7 and 6. Azul’s CVE list records it as CVE-2026-91403. For runtimes that could not be updated right away, Azul also published a manual workaround that replaces the block list file.
  • October 24: Azul found that the block list did not fully close the problem. The second out-of-cycle update fixes CVE-2026-114820 (JSSE, base score 9.1) by removing certain CA certificates from cacerts altogether. At the time of writing, these builds are available for Azul’s security-only CPU line, both on the October 2026 CPU base (for example Zulu 21.53.114, 17.69.114, 11.91.114 and 8.97.0.112) and on the July 2026 CPU base. Azul says PSU builds “will likely” follow in a separate update.

The October 24 update changes the advice. Azul’s workaround page now warns that it “no longer fully addresses the problem,” and Azul tells all customers to update to the latest release. If you applied the October 21 update or the workaround, you still need the October 24 build. In its own write-up, Azul says it took about 12 hours from the decision to respin to security-only builds in customers’ hands.

What BellSoft shipped for Liberica JDK

BellSoft published its regular October 2026 Liberica JDK release on October 21. That quarterly release lists 52 fixed CVEs and includes CPU builds for Java 6 and 7 (6u521 and 7u521). Its release notes do not cover the eMudhra issue.

BellSoft covers eMudhra in a separate guide, “Distrusting compromised eMudhra intermediates in Java” (last updated October 27). It lists the fixed builds as Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 and 27.0.1.0.3+5. For systems that cannot update yet, the guide gives a temporary mitigation: remove the affected roots from the trust store. It warns that this can break legitimate certificate chains and should be tested first.

Two points matter when you compare vendors:

  • The CVE lists are not the same. Azul and BellSoft each publish their own CVE list for the October cycle, and the counts and notes differ. The two Azul CVE IDs above come from Azul’s records. BellSoft’s guide does not cite them. Check your own vendor’s release notes for the exact fixes in your build, and do not assume one vendor’s list applies to another vendor’s JDK.
  • Java 6 and 7 are not on BellSoft’s eMudhra list. BellSoft’s latest Java 6 and 7 builds are available, but the fixed-build list in its eMudhra guide starts at Java 8. If you run Liberica 6 or 7, ask whether your build includes the trust-store change before you rely on it, or apply the vendor’s mitigation. Azul lists October 24 builds for Zulu 6 and 7.

How LOGIQ responded

We distribute Java builds from BellSoft and Azul to our customers and help them migrate away from older Oracle JDK versions. Here is what we did, with the status of each item at the time of writing (October 29).

Done

  • October 21–22: vendor notices reviewed. We received and reviewed Azul’s October 21 out-of-cycle notice and BellSoft’s October 2026 release notice. We opened download and repository tasks for both vendors the same day. We treated the two releases separately and did not assume BellSoft’s quarterly release contained the same eMudhra fix as Azul’s.
  • October 23: Liberica quarterly builds staged. We downloaded the October 2026 Liberica JDK builds from BellSoft’s support portal and added them to the repository our customers download from.
  • October 24–25: second Azul update tracked. We picked up Azul’s October 24 notice, including its advice to update even if the October 21 build was already installed.
  • October 27–28: fixed Liberica builds obtained through BellSoft. We asked BellSoft, through our commercial support relationship, to make the newest builds available on our support portal. BellSoft uploaded them on October 28, including the fixed builds for Java 8, 11, 17, 21, 25 and 27 and the latest Java 6 and 7 builds. Some customers still need 32-bit Java 8, so we also asked BellSoft to add the 32-bit 8u513+9 installers for Windows and Linux to our portal. BellSoft added them the same day.
  • October 28–29: repository and migration mappings updated. We added these builds to our customer download repository and updated our Oracle JDK-to-Liberica migration guidance to point to them, with a second engineer reviewing the update.

Azul Zulu customers

Azul’s October 21 and October 24 builds are available to Azul subscribers through Azul. The right build depends on your Java version, whether you use the CPU or PSU line, and which base (October or July) you are on. Check Azul’s release notes for your exact build, or ask us and we will help you identify it.

Legacy Java 6 and 7

Some customers still run Java 6 or 7, often in applications that cannot move quickly. Oracle no longer provides public updates for these versions, but they are not without options. We help customers migrate from old Oracle JDK 6 and 7 builds to the latest Liberica JDK 6 and 7 builds, and BellSoft’s October 2026 builds for both versions are available to us through BellSoft’s support portal. When a fix or package we need for these versions is missing, we escalate it to BellSoft through our commercial support channel. For this incident, see the note above: confirm that your Java 6 or 7 build includes the eMudhra trust-store change before you rely on it.

What you should do now

1. Find every Java runtime

List every place Java runs, not just the system JDK. That includes application servers, bundled runtimes inside vendor products, jlink images, CI build agents and every container image. On Linux, this finds Java binaries on a host:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

For container images, run the check inside the image, for example docker run --rm --entrypoint java <image> -version.

2. Check the exact vendor and build

The major version is not enough. You need the vendor and the full build number to match against the vendor’s fixed-build list:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

As a quick indicator, you can also list the eMudhra (emSign) roots in a runtime’s trust store:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

In our tests with BellSoft’s public container images, an older Liberica 21.0.10 build listed five emSign roots, while the fixed 21.0.13.0.3+5 and 8u513 builds listed none. An empty result is a good sign but not proof. The October 21 Azul fix, for example, blocked the intermediates without removing roots. The build number is the reliable check. Our earlier article on checking Java truststores covers more detailed checks.

3. Get the latest applicable patch

  • Azul Zulu: move to the October 24 out-of-cycle build for your line (CPU or PSU, October or July base), even if you installed the October 21 build or applied the workaround. If you are on PSU builds, watch for Azul’s follow-up PSU release.
  • Liberica JDK: move to the fixed builds listed by BellSoft (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Other vendors and bundled runtimes: check that vendor’s advisory. A JDK inside a third-party product is updated by that product’s vendor, not by your OS updates.
  • Containers: rebuild images on a fixed base image and redeploy. Patching a running container does not change the image.

4. Validate TLS before and during rollout

Removing roots from a trust store can break legitimate connections, for example to sites that still use certificates chaining to the removed eMudhra roots. eMudhra says it is reissuing affected customer certificates from an alternate CA hierarchy. Before a wide rollout, test the outbound TLS connections your applications depend on, especially to partners or services that may use eMudhra certificates. Roll out in stages, restart the Java processes so they load the new trust store, and confirm the running version afterwards.

5. Watch for out-of-cycle releases

This incident produced two emergency Java releases in four days, and more may follow, such as Azul’s PSU builds. Subscribe to your vendors’ security notices, check their release pages directly instead of relying only on email, and plan for Java updates outside the quarterly schedule.

The lesson

Firefox users were protected within hours because browsers have their own trust stores and an automatic way to update them. Enterprise Java has many trust stores, no default revocation checks, and updates that wait for someone to install them. Closing that gap takes an accurate inventory, exact build numbers, fast access to vendor builds, and a process that does not wait for the next quarterly patch. If you need help finding or updating the Java runtimes in your environment, contact LOGIQ.

References