Agentic AI and the Java patch cycle: why quarterly patching is not enough

According to Azul, attackers increasingly use AI agents to find, chain, and exploit vulnerabilities, and even a low-rated vulnerability can be combined with others into a working exploit within hours. In its M-Trends 2026 report, Google does not yet consider 2025 the year in which breaches were the direct result of AI. The direction is clear, though: there is less and less time to react, and AI may shorten it further.

Java is no exception. And most enterprise Java estates are still set up for a world in which a few weeks to patch was fine.

Three numbers that sum it up

• −7 days: M-Trends 2026 estimates mean time to exploit at −7 days, so exploitation routinely starts before a patch ships. The figure covers vulnerabilities in general, not Java specifically.
• 43 days: the median time to full remediation of CISA KEV vulnerabilities (from detection, median per organization), according to Verizon DBIR 2026. A year earlier it was 32 days.
• +20%: compound quarterly growth in OpenJDK vulnerabilities over the past two years, according to Azul's analysis of quarterly releases from October 2024 to October 2026.

Attackers are speeding up, patching is slowing down, and vulnerabilities keep growing. Working harder will not close that gap. What gets deployed, and how, has to change.

Why Java patches so often wait

According to Azul, most organizations, whether they pay for support or not, receive cumulative quarterly OpenJDK updates. These bundle security fixes with hundreds of other changes. According to Azul's records, more than 20% of these updates since 2020 included regressions that prevented their timely rollout.

An operations team then faces an unpleasant choice:

1. Deploy the quarterly update and risk functional or performance impact on applications.
2. Roll it back and stay exposed to a potential attack.

Monthly Critical Security Patch Updates (CSPUs) do not solve this on their own if they are built on the same quarterly update that contains the regression. According to Azul, an organization then cannot deploy such a patch until the regression is fixed, at a time when, Azul says, AI is lowering the time and skill needed to exploit a newly disclosed vulnerability.

CPU, PSU, and CSPU: what's the difference

The core idea is simple: separate security fixes from everything else. An update with security fixes only means far fewer changes to validate, so it can be deployed faster. Other changes can be tested without time pressure.

A four-step approach

According to Azul, this is how it looks with Security-only, Stability-first™ updates:

1. See what you have. You can't patch what you can't see. Azul JVM Inventory uses live data to show the vendor, version, patch level, and application behind each JVM, including short-lived containers that periodic scans often miss.
2. Patch production now. Deploy security-only CPUs and CSPUs as soon as they ship. Azul typically releases them within an hour of disclosure.
3. Test at your pace. You can validate full quarterly updates in pre-production for three months before non-security changes reach production.
4. Cover zero-days. Out-of-cycle updates and 24×7 SLA-backed support cover critical vulnerabilities disclosed between scheduled releases.

Moving from Oracle JDK or another distribution does not have to be a big project. Azul Core and Azul Prime are TCK-verified and built from OpenJDK, so it is usually a binary swap rather than a code change. Security-only updates are available for all current LTS versions (8, 11, 17, 21, and 25), with backported security fixes for Java 6 and 7 as well.

For a real example, see the eMudhra case from October 2026.

Audits and regulation

PCI DSS and DORA explicitly require vulnerability and patch management, and in Europe NIS2 covers the same ground. SOC 2 audits and SOX IT controls often reach it indirectly. In practice, that means being able to demonstrate three things:

• visibility into deployed software versions,
• timely remediation of known Java vulnerabilities within the deadlines you set,
• a documented patch history and usage data for audits.

Relying on a system behind a firewall passing an audit is increasingly risky, because attackers often get in another way and then look for exactly these neglected systems.

Where to start

Before you change anything, you need to know where you stand. That is why, together with Azul, we offer a free Java Security Assessment: in as little as a few days you can see which versions have KEV exposure, which are below the current CPU level, and where end-of-life versions run. We describe it in detail in this article.

Request the free assessment. It is free, carries no obligation, and everything goes through us.