Azul Statement on the eMudhra Intermediate CA Certificates Compromise
Security CVE campaign Zoom_Teams Background & email signature banner (1)

Agentic AI changed the Java security landscape. Your unsupported patch cycle is now a liability.

Quarterly update release delays, testing cycles and regression risks leave enterprises exposed for days to weeks, while agentic AI exploits are being built and launched within hours of disclosure. 

Java Security

One Week in October

Java trusts what ships inside the JDK. A compromised certificate authority becomes a patching problem for every runtime.

security

October 20th: Record Volume

Within an hour of disclosure, Azul shipped the Security-only, Stability-first™ October quarterly update, closing a record 53 CVEs.

security

October 21st: eMudhra, First Fix

Eight eMudhra intermediate CA certificates were compromised. Azul shipped a security-only build to address the first zero-day OpenJDK critical CVE-2026-91403 in under 24 hours.

security

October 24th: eMudhra, Second Fix

Azul shipped the second eMudhra zero-day fix for critical CVE-2026-114820 about 12 hours later.

mean_time_to_exploit_trend_1

Exploitation now happens before disclosure

Mean Time-to-Exploit, the gap between a CVE going public and the first confirmed exploit in the wild, has been on one trajectory for nine years straight.

java_se_patches_issued_1

The patch gap risk keeps growing

Agentic AI doesn’t need a critical vulnerability to exploit. It can chain together multiple lower risk flaws. Quarterly patches are only heading in one direction, giving AI more weaknesses to exploit.

Two Options; One Solution

The risk looks different depending on how your organization currently runs Java.

Risk Self-Supported Java/OpenJDK Commercially Supported Java/Azul Core

Speed under machine-speed attacks

The organization must extensively test PSUs and targeted monthly Critical Security Patch Updates (CSPUs) to keep pace with the speed of AI-driven exploits.

Azul’s Security-only, Stability-first(™) CPUs and CSPUs typically contain only a handful of security fixes, offering an immediately deployable, security-only path. 

Update availability

Full quarterly updates are typically provided on a best effort basis, sometimes days to weeks after disclosure.

Azul’s CPUs and CSPUs are released on a strict SLA, typically within one hour of disclosure.

Update validation

The organization’s team owns regression testing of full updates, which can take days.

Azul’s security-only CPUs are suitable for immediate deployment.

Regressions

~20% of full updates (5 in 24) result in regression issues.

Azul’s CPUs have minimal regression risk.

Enterprise-specific regression escalations

No guaranteed community response or timeline.

Azul provides an SLA-backed escalation path to a patch.

Zero-day vulnerabilities

Best effort, out-of-cycle fixes from the community.

Azul provides out-of-cycle fixes upon critical disclosures.

Cost profile 

Variable engineering and incident cost.

Azul’s fixed, budgetable subscription plus low-overhead internal deployment work.

Insurance posture

Increased premiums; increased claim rejection rate.

No negative impact.

Knowledge risk 

Expertise may be lost, or concentrated in a small number of engineers. 

Azul has the largest Java team outside Oracle.

Legacy technology

No patches for legacy technology like Java 6 and 7.

Azul backports security fixes for Java 6 and 7.

Security-only, Stability-first™️ updates enable AI-era patch cycle velocity

Patch as fast as agentic AI attacks move. Azul is the only OpenJDK vendor closing the gap between AI-driven exploitation and the typical weeks-long enterprise patch cycle, with Security-only, Stability-first(™) quarterly, monthly and out-of-cycle updates built for rapid deployment to meet security and regulatory requirements.

Fast, stable & secure. Choose any three

Deploy immediately, with no testing delay. Our quarterly CPUs and targeted monthly CSPUs are Security-only, Stability-first™ patches that have already passed extensive regression testing, built on the prior quarter’s community-tested update with only the new security fixes added.

Comprehensive security

Stay covered on a firm SLA, not a best-effort promise. We deliver quarterly and targeted monthly updates ready for immediate production deployment, full quarterly patch updates for non-production testing, and out-of-cycle fixes to address zero-day vulnerabilities, all in partnership with the Java community.

Frequently asked questions

How do I know if the Java I’m running is actually unsupported?

Check your JDK vendor and version against that vendor’s published support and end-of-life dates. If you’re on Oracle Java without an active support contract, or on a build past its vendor’s patch window, you’re very likely running unsupported Java. Most teams need a scan across their actual environments to get a definitive inventory, since manual tracking rarely catches everything.

How long does it typically take to exploit a newly disclosed Java vulnerability?

Mean time to exploit is now negative 7 days meaning exploitation routinely occurs before a patch is released. This is compared to the median time organizations take to remediate a known vulnerability, which is now 43 days.

Does running unsupported Java create a compliance problem?

Yes, in most cases. Standards such as SOC 2, PCI DSS, and HIPAA generally require that software stay patched against known vulnerabilities. Unsupported Java, where no vendor is providing security fixes, typically can’t meet that requirement regardless of Oracle licensing status.

Does moving to a supported Java distribution mean rewriting code or changing JDK versions?

No. A drop-in, OpenJDK-compatible distribution runs the same bytecode and APIs as your current build, so switching vendors is typically a binary swap, not a code change or version migration.

How long does it actually take to get off unsupported Java?

For most enterprises, moving to a supported OpenJDK distribution takes days to a few weeks per environment, since it’s a drop-in replacement rather than a migration project. Testing and internal change-management process usually drive the timeline more than the technical switch itself.

What happened with the eMudhra certificates? 

Eight intermediate CA certificates were revoked. Major browsers blocked or distrusted the affected certificate chains. Java does not check certificate revocation by default, so each JDK kept trusting them until the JDK’s certificate store was updated. Updating to Azul’s out-of-cycle fix shipped on Oct 24 fixes the issue.

Talk to a Java Expert

Switch to supported Java without rewriting code or changing JDK versions.