Far too many organizations are still running unsupported Java without realizing that the Java security landscape has fundamentally changed due to AI. Best-effort quarterly patch releases and standard patching cycles are no longer best practices; they’re now your biggest liability.
If you haven’t been following the evolution of agentic AI-driven attacks, the most recent Anthropic “misuse of AI” report from September 2026 will alarm you:
- Multi-agent frameworks can now run reconnaissance, exploitation, and data theft against multiple victims in parallel for hours or days with minimal human supervision.
- Chinese-speaking operators (some identified as undergraduates) hit roughly 50 organizations across eight sectors and ran an autonomous vulnerability-research program producing working exploits against network and security appliances.
- Opportunistic hackers are using AI to accelerate their broad-based scanning techniques that identify and probe unpatched internet-facing systems. The attacks exploit known vulnerabilities to compromise or take over the target systems before they can be patched.
This is just three of dozens of types of attacks described in the report. The point is that AI has collapsed the time and resources needed to create and launch attacks from teams of technical hackers working for weeks to anyone with malicious intent and a couple of spare hours.
Java is not immune: an AI-orchestrated global cyberattack campaign used AI agents to chain together two vulnerabilities in PaperCut’s Java-based print management software. The AI created an exploit and launched the attack within 4 hours of disclosure, compromising at least 440 server instances across 395 organizations in 48 countries. At peak execution, a swarm of hundreds of AI agents compromised 11 organizations in just 26 seconds, with some environments moving from initial breach to full domain administrator access in 7 minutes.
This kind of example is a big reason why the average time between when a vulnerability is publicly announced and actively exploited has shrunk from weeks to negative time between 2025 and 2026.
We covered this shift in Your Java Patching Cycle Was Designed for a Slower Enemy and Get Your Java Estate Ready for the Growing Agentic AI Threat. The short version: a patch cadence that assumes weeks of runway is an existential danger to your business.
How to think about your “free OpenJDK” vendor
Here is the uncomfortable part, and it applies to Azul’s free downloads as much as anyone else’s.
A free build of OpenJDK carries no commitment about when the next security release ships, no obligation to backport a fix to the version you actually have in production, and nobody to call at 2 a.m. when that patch causes a production issue. Patches arrive based on best effort, in many cases days to weeks after disclosure, sometimes longer for older versions that the maintainer has moved on from.
That isn’t a criticism of free builds. Azul publishes free Azul Zulu Builds of OpenJDK, and they are the right choice for development machines, CI runners, evaluation, and other non-production, non-public-facing workloads where a multi-week exposure window is an acceptable risk. But in the age of agentic AI, unsupported OpenJDK, including Zulu, is simply unsuitable for production. The difference between a free build and a subscription isn’t the bytecode; it’s an SLA-backed, scheduled security release, backported across supported versions, and someone contractually on the hook for both.
| Free / Unsupported OpenJDK | Azul Core | |
| Security patching | Best-effort builds, days to weeks after disclosure | Scheduled Security-only, Stability-first releases, backed by a strict SLA |
| Patches for older versions | Coverage depends on maintainer interest | Java 6+ |
The unsupported OpenJDK motion
If you’re running free, unsupported OpenJDK builds, it’s usually because either:
- Nobody made a decision. In other words, someone started using a convenient option, and it quietly became the production standard. This is common, not an exception. It just means the risk position was never actually chosen.
- The business prioritized budget over security. That decision trickles down to teams who feel justified in deprioritizing security efforts. The result is:
- A Java 6 deployment with >400 known vulnerabilities that has been scheduled to be retired/upgraded every year for the past 5 years.
- A policy to fix only critical JDK vulnerabilities, which last occurred in April 2019. The result is production systems with >60 vulnerabilities rated as high risk.
- A reluctance to deploy PSUs since they require extensive testing: ~20% of PSUs have caused a regression issue (5 out of 24) since July 2020.
None of this is hypothetical. The pattern consistently recurs across Azul’s Java estate assessments: end-of-life Java 6 and 7 still in production, JVMs well behind current patch baselines, and KEV-listed vulnerabilities sitting unaddressed simply because nobody knew those runtimes were there. The following dashboard represents a fictional company’s assessment, but it’s highly representative of the actual assessments we perform.
To be fair, some unsupported OpenJDK users have excellent security practices, while some supported users do not, but they are exceptions. If there’s a silver lining, it’s the fact that two or three JVM versions account for the bulk of the exposure. Applying a few up-to-date patches typically resolves ~70% of the issues.
Migrating from Oracle Java? Beware of the tradeoff
Enterprises are increasingly migrating off Oracle Java, primarily for cost reasons. But moving from Oracle Java to a free, unsupported build trades a budget problem for a security one: you eliminate the license cost, but inherit a lesser patching cadence since you lose access to:
- Security-only builds – both quarterly and monthly
- Out of cycle patches – unsupported OpenJDK vendors provide out-of-cycle patches on a best-effort basis but provide no commitment.
That trade is worth making deliberately, if you make it deliberately. It’s a different decision from the one most teams think they’re making, which is simply “stop paying Oracle.”
What supported changes, in one customer’s numbers
Ausgrid, the largest electricity distributor in New South Wales, moved off Oracle Java to Azul. In addition to eliminating an estimated $700,000 per year in potential audit exposure, they cut outstanding vulnerabilities by 99%.
What to do this quarter
Inventory every JDK in production, including the ones nobody remembers deploying. This is the step most teams skip and the one everything else depends on. You cannot assess exposure against an estate you can’t see, and the versions that turn up are reliably older than expected.
Measure your actual patch latency, not your intended one. Take a recent cycle and work out how many days passed before those fixes reached production. That number is your real exposure window, and it’s the one an incident review will use.
Get a scoped assessment before the next disclosure cycle, not after. The difference between finding a KEV-listed vulnerability on your own schedule and finding it on an attacker’s is the entire argument of this post.
The clock already ran out
Mean time to exploit going negative is a change in the order of events: the exploit can exist before the advisory that would have told you to patch.
A runtime that patches on best effort was a reasonable risk when the window was three weeks. That window is gone now, never to return, and every disclosure cycle from here is a test of whether your estate is on a schedule or on a volunteer’s goodwill.
Frequently Asked Questions
How quickly are security patches available for free OpenJDK builds?
There is no committed timeline, which is the defining difference between a free build and a supported one. Free distributions publish security rebuilds on best effort, typically days to weeks after a vulnerability is disclosed, and older versions may wait longer or not be rebuilt at all if the maintainer has moved on. Azul Core ships security-only releases on a schedule, backported across supported versions, with an SLA behind the delivery. Azul also publishes free Azul Zulu Builds of OpenJDK, which carry no such commitment by design.
How many known vulnerabilities are in end-of-life Java versions?
More than most teams expect, and they accumulate rather than expire. JDK 6 carries 425 known vulnerabilities that have gone unpatched since 2013, 89 of them rated critical. JDK 8 has had 444 vulnerabilities addressed since 2015, 68 of them critical, fixes that reach a supported runtime automatically and do not reach an unsupported one at all. Azul Core provides security updates for Java 8 and later, including versions that are past end of public updates elsewhere.
Does AI make Java vulnerabilities easier to exploit?
Yes, and the measurable effect is on timing rather than technique. Verizon’s 2026 Data Breach Investigations Report found vulnerability exploitation is now the leading initial breach vector at 31% of breaches, up 55% year over year, while the mean time between disclosure and active exploitation has gone from 21.5 days in 2025 to negative, with exploits appearing before the CVE is published. Academic research has demonstrated large language models autonomously exploiting one-day vulnerabilities at an 87% success rate without human involvement. For a runtime patched on best effort, that compression turns a tolerable delay into an open window.
What are the security trade-offs of running free OpenJDK in production?
The trade is cost against patch latency and accountability. A free build is functionally equivalent code, so the risk is not in the bytecode; it is that no one is committed to shipping you a fix for the version you run, on a known schedule, with evidence you can produce afterwards. That is an acceptable trade for development environments, CI, and workloads that tolerate a multi-week exposure window. For systems where a known exploited vulnerability sitting unpatched for weeks is not acceptable, a supported distribution such as Azul Core is the control being purchased.
How do I find out which Java versions are actually running in my environment?
Start by discovering running JVMs rather than auditing installation records, because the two rarely match and installed-but-forgotten runtimes are where unpatched versions hide. Most estates turn out to contain end-of-life Java 6 and 7 in production and JVMs well behind current patch baselines. Azul Intelligence Cloud catalogs and classifies both running and installed JVMs by vendor, version, and location, which is what makes exposure measurable rather than estimated. In most large environments, two or three JVM versions account for the bulk of the risk, so remediation is usually more concentrated than the inventory first suggests.
