October was a rough month for maintaining maximum security in enterprise application runtimes.
On October 21, the PHP project shipped emergency fixes for two critical remote code execution (RCE) flaws in the interpreter itself. One project, one set of releases, one answer to the question “am I patched?”
Java’s week looked different. The scheduled October OpenJDK update contained patches addressing 53 CVEs. This is an all-time-record high for a quarterly update, over three times the two-year average prior to July this year of 7.6 CVEs per update. None of these was critical, but as we now know, AI can chain together lower-scoring vulnerabilities to generate an effective exploit. Not worrying about low and medium scores used to be an option, but not anymore.
Such a large number of security patches brings with it considerable challenges for OpenJDK maintainers. These 53 CVEs are upstreamed to the OpenJDK 27 repository via the OpenJDK Vulnerability Group, which includes engineers from organizations like Azul, Amazon, Microsoft, and SAP. It is these engineers, not those from Oracle, who are responsible for backporting security patches (where relevant) to the older LTS versions. At the time of writing, nine days after the release of the update, there are still no general availability (ga) tags for JDK8u512 or JDK 11.0.33. This clearly impacts any distribution that builds just from the OpenJDK repository. They are just not able to deliver an update.
eMudhra, We Have a Problem
Things got worse a day later with the revelation that eight intermediate CA certificates, created in April 2025 under eMudhra’s emSign brand, had private keys weak enough for anyone to recover. Six were for TLS and two for code signing.
The eMudhra compromise triggered a critical security crisis for the Java ecosystem.
A browser can stop trusting a CA overnight because its vendor controls the root store and can push changes in the background. A standalone JDK has no such channel. It decides which roots to trust from a file that ships with it, lib/security/cacerts, and it keeps a separate blocklist of known-bad certificates in lib/security/blocked.certs. Updating the browser or the operating system changes neither file.
Two further details made this incident awkward for Java:
- Revocation is off by default. Java’s TLS stack does not check certificate revocation lists or Certificate Transparency logs unless you configure it to. The browsers’ fast response relied on exactly the mechanisms Java skips.
- There were two trust paths. The compromised intermediates chained to eMudhra’s emSign ECC Root CA – G3. But Sectigo had also cross-signed the same keys under its AAA Certificate Services root, so a forged certificate could validate through either root. Removing only the emSign root closes one path and leaves the other.
The escalation moved so fast that Oracle had to issue two distinct security alerts back-to-back as the initial fix proved insufficient:
Round 1: CVE-2026-91403 (Issued October 21, 2026)
Oracle released an emergency advisory (CVSS 9.1). The initial fix (e.g., JDK 11.0.33.0.2 and 8u511) attempted to surgically block the 8 compromised eMudhra intermediates (and their 8 Sectigo cross-signed versions, 16 certificates total) by appending their SHA-256 hashes to the JDK’s internal lib/security/blocked.certs file.
Round 2: CVE-2026-114820 (Issued October 24, 2026)
Just days later, Sonatype published a blog explaining that blocklisting the specific intermediate fingerprints wasn’t aggressive enough to completely isolate the threat across all deployment scenarios. Oracle issued a second emergency patch. This update completely removed the eMudhra root certificates from the JDK cacerts keystore.
When and Where Do You Get Your Patches?
OpenJDK is a source code project and does not provide the binaries you install to run your Java applications. For this, we rely on distributions from providers like Azul, Amazon, Red Hat, Adoptium, and Oracle.
These are all clearly different organizations with different engineering teams and differing resources. This can have a significant impact on how (and even if) you can get an update that includes the patches you need to ensure the maximum level of security.
A commercially supported Java runtime, like Azul Core, comes with Service Level Agreements (SLAs) on how quickly patches will be made available. Azul does not rely on the OpenJDK repositories, so it can build and deliver updated binaries before the repos are fully updated. When you have a critical vulnerability like eMudhra, can you afford to wait days, or even weeks, to be able to deploy a patch?
Applications, Libraries, Runtimes: Different, Yet the Same
In both the PHP and Java cases, the problem sat below the application, so fixing your own application code changed nothing. PHP’s flaws were in the interpreter, and a clean WordPress plugin was no defense. Java’s problem was in the trust store that ships with the runtime, and a clean Spring service was no defense either. The runtime and its bundled files are dependencies, and they belong in your inventory.
Compliance Is Not an Option
Compliance regulators are also taking note of the increased threat level posed by AI-led vulnerability detection and exploitation. In the UK, the Cyber Essentials update that took effect in April makes missing a 14-day window for critical patches an automatic certification failure. Unsupported software on an in-scope device fails you outright.
Compliance requires a director-level signature on a declaration to maintain the controls for the year. Somebody’s name is on this now.
In the US, federal suppliers face CISA’s new risk-based directive, with 72-hour windows for the worst cases. The same CVEs, but how different distributions deliver patches can vary wildly.
Where Do We Go from Here?
The only constant is change, and the amount of change for security patches in the Java runtime is likely to keep growing, at least in the short to medium term. Increased use of ever more sophisticated models will continue to identify security weaknesses of greater complexity. Combined with agentic AI’s ability to chain together more benign vulnerabilities into practical exploits, this will place a much greater workload on the DevOps teams responsible for patching.
Choosing the right Java runtime distribution is even more critical to ensuring your enterprise applications maintain the maximum level of security.
FAQ
Why doesn’t updating my browser or operating system protect Java applications from a compromised certificate authority?
Java doesn’t use the browser’s or the operating system’s trust decisions. Every JDK decides which certificate authorities to trust from its own file, lib/security/cacerts, and keeps a separate blocklist in lib/security/blocked.certs, so neither changes until the JDK itself is updated. Azul Core, a commercially supported Java runtime, delivered security-only updates for the eMudhra compromise on October 21 and October 24, 2026.
How do JDK distributions differ in how quickly they deliver Java security patches?
OpenJDK is a source code project, and the binaries you install come from distributions such as Azul, Amazon, Red Hat, Adoptium, and Oracle, each with different engineering teams and resources. Distributions that build only from the OpenJDK repositories can’t ship until those repositories are updated: nine days after the October 2026 update, JDK 8u512 and JDK 11.0.33 still had no general availability tags. Azul Core comes with SLAs on how quickly patches are made available, and Azul does not rely on the OpenJDK repositories, so it can deliver updated binaries before they are fully updated.
What do I need to update to protect Java applications from the eMudhra certificate compromise?
The compromise needed two fixes. The first, CVE-2026-91403 (October 21, 2026), added 16 certificates, the eight compromised eMudhra intermediates and their eight Sectigo cross-signed versions, to the JDK’s blocked.certs file. The second, CVE-2026-114820 (October 24, 2026), removed the eMudhra root certificates from the JDK cacerts keystore, so runtimes that applied only the first update need the second. Azul Core and Azul Prime customers should update to the October 24 builds, even if they applied the October 21 builds.
What do compliance rules require for patching critical Java vulnerabilities?
In the UK, the Cyber Essentials update that took effect in April makes missing a 14-day window for critical patches an automatic certification failure, and unsupported software on an in-scope device fails outright. In the US, federal suppliers face CISA’s new risk-based directive, with 72-hour windows for the worst cases. A commercially supported distribution such as Azul Core, with SLAs on patch availability, gives teams a defined timeline to measure against those windows.
