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.
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.
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.
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. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
Switch to supported Java without rewriting code or changing JDK versions.