Security leaders know the threat has changed. What the data suggests is that their patch processes have not. According to The 2026 AI Vulnerability Gap Report from Azul, released on 11 November, 85% of organisations running significant volumes of Java have already experienced an incident, suspected incident or near miss attributable to slow patching. That figure includes 55% who report a confirmed incident and 53% who report a near miss, with respondents able to select both.
The report is based on a survey of 300 U.S. security leaders at organisations where Java makes up a significant share of the production application estate, conducted independently by Censuswide. Its central theme is that AI is shrinking the time attackers need to exploit newly disclosed vulnerabilities while enterprise defences remain, in the words of Azul’s chief executive, built for a slower era.
“Agentic AI has collapsed the margin defenders depend on, and most enterprises are still running patch processes built for a much slower adversary,” said Scott Sellers, co-founder and CEO of Azul. “Our research shows security leaders understand the threat: awareness is no longer the gap; execution is.”
Exploitation is outrunning patching
The context is a hard one. Azul notes that October’s OpenJDK quarterly update disclosed a record 53 vulnerabilities, the most in a single update in well over a decade. Virtually every leader surveyed said AI-powered attack tools have increased their organisation’s security exposure over the past 12 months. Yet 59% have not changed their security posture: 34% describe a moderate increase and say they are reassessing, while 25% call the increase slight and not a priority.
Leaders’ expectations about attackers are stark. Some 69% believe AI-equipped attackers can build a working exploit within three days or less, including 47% who say one to three days and 22% who say less than 24 hours. The report also cites Mandiant’s M-Trends 2026, which estimates that the mean time to exploit fell to negative seven days in 2025, meaning exploitation often occurs before a patch is even released.
The three-day gap
Against that backdrop, the speed of enterprise response looks thin. Only 13% of security leaders say they can deploy a patch for a critical vulnerability across production in under 24 hours. Another 43% need one to three days, 32% need four to six days and 12% need longer. Put differently, 69% believe an attacker can build a working exploit within three days, but only 56% of organisations can get a critical fix out in that time. The same mismatch appears at the 24-hour mark: 22% believe attackers already work inside that window, while just 13% can deploy that fast.
Testing is a major reason. When asked how much pre-deployment testing adds to the patch cycle for Java runtime updates, 36% said four to six days, 33% said one to three days and 22% said a week or more. Only 9% said less than 24 hours, and no respondent skips testing. In total, 58% of organisations add four or more days of testing alone, longer than the three days or less most leaders believe an attacker needs.
The burden exists because Java updates often carry more than security fixes. A full OpenJDK quarterly update can include hundreds of non-security code changes alongside the security patches, and Azul’s assessment of OpenJDK releases over the past six-plus years found that 23% of quarterly updates, six of 26, caused a serious regression. Enterprises are left trading security against stability, and many choose caution.
The estate nobody fully accounts for
Speed is only part of the problem. Java runs beneath many critical business applications, and as teams, acquisitions and cloud migrations have multiplied runtimes, few organisations have a complete picture of where they all are. Because Java runs reliably and rarely causes trouble, it often gets less scrutiny than it deserves.
Only 19% of leaders said nearly all of their production Java runtime estate, 90% or more, is on the latest available security patch level. That leaves 81% with gaps in coverage, including 21% who say half or less of their estate is current. Visibility is the second blind spot. While 49% claim full visibility into every instance of their critical Java runtimes, including embedded, legacy and unmanaged ones, 51% concede they have only partial or limited visibility and suspect there are instances they cannot see. Azul argues that even the 49% figure is probably optimistic, since missing instances are invisible to the tools that should report them. The same logic leads it to suggest the 85% incident figure is likely an undercount, because an incident can only be traced back to an unpatched system the organisation knew it had.
The October compromise of eight eMudhra intermediate certificate authority keys illustrates the cost. Browser vendors blocked the affected certificates, but Java runtimes keep their own trust stores and do not check revocation by default. Every runtime, including those embedded in applications and containers, needed its own update.
Intent is not a deadline
Policy discipline is uneven. Two-thirds of organisations, 66%, have no mandated, time-bound commitment for patching non-critical vulnerabilities. Some 38% patch on a “best effort” basis, 33% mandate a defined service-level agreement, 25% take a risk-based approach and patch only what is judged high priority, and 3% have no formal policy at all.
That matters because attackers are gaining new tools for chaining weaknesses together. Azul points to a July 2026 OpenAI evaluation in which autonomous agents running with reduced safeguards chained vulnerabilities to escape their test sandbox and gain unauthorised access to Hugging Face systems. Unpatched low-priority flaws, in other words, can become stepping stones.
Asked about the biggest barriers to patching quickly, leaders put three internal constraints on top: extensive pre-deployment testing at 44%, the complexity or age of affected systems at 40% and limited visibility into known vulnerabilities at 36%. Delays in receiving patches from vendors was among the least cited, at 25%, and it is the only barrier on the list that sits outside the enterprise’s control. For CIOs and CISOs, that is both uncomfortable and useful. The main obstacles are ones the organisation can fix itself.
Where leaders are placing their bets
Looking ahead, 32% of leaders name faster and more frequent patching as their primary strategy for reducing exposure, and 26% name better visibility and inventory of software and runtimes. Another 17% plan to invest in detection and response rather than faster patching. Together, patching speed and visibility account for 58% of primary strategies, and they map onto the two problems the report traces: you cannot patch what you have not found, and finding it does not help if remediation takes longer than exploitation.
Sellers frames the choice as one of exposure time. “No one can eliminate zero-day risk, but every organization decides how long it stays exposed by how much of its Java estate it can see and how fast a fix can move through it,” he said.
If most leaders believe exploits can be built in three days or less, and more than half of their organisations need four or more days just to test a fix, the window stays open by design. Closing it means shrinking testing time, finding the runtimes nobody has inventoried and replacing “best effort” with deadlines that can be audited.
Awareness, as Sellers notes, is no longer the gap. The organisations that close this one first will be those that treat the time between a fix becoming available and reaching production as a number to be measured, owned and driven down, before an attacker does the measuring for them.
Source: The 2026 AI Vulnerability Gap Report, Azul, 11 November 2026. Survey of 300 U.S. security leaders conducted by Censuswide.