Azul report finds Java patching trails exploit timelines

Azul says Censuswide conducted the survey among 300 U.S. security leaders at organizations where Java is a significant share of production applications.[1] Azul reports that 85% of respondents had experienced an incident, suspected incident or near miss attributable to slow patching.[1] That figure reflects respondents’ reported experience and does not establish that AI caused those events, Azul says.[2] The report also gives different results by country: 91% in the UK, 85% in the U.S. and 93% in Germany reported an incident or near miss attributable to the patch gap.[4]

Azul says 69% of surveyed leaders believe AI-equipped attackers can build a working exploit within three days or less; 47% estimate one to three days and 22% under 24 hours.[1] On the defensive side, 13% say they can patch a critical production vulnerability in under 24 hours, 43% need one to three days, 32% need four to six days and 12% need longer.[1] Overall, 56% say they can deploy a critical fix within three days, compared with the 69% who expect attackers to build an exploit within that period.[1] Azul also cites an estimate that mean time to exploit fell to negative seven days in 2025, with exploitation often preceding patch release.[1]

Azul says 58% of surveyed organizations add four or more days of testing alone.[1] In the reported breakdown, 36% said pre-deployment testing takes four to six days, 33% said one to three days and 22% said a week or more.[1] No survey respondent said they skip testing Java runtime updates.[1] Azul says a full OpenJDK quarterly update can include hundreds of non-security code changes alongside security fixes, and reports that six of 26 quarterly updates caused a serious regression.[1]

The leading cited barriers to faster patching were extensive testing at 44%, system complexity or age at 40%, and limited vulnerability visibility at 36%, according to Azul.[2] Azul says 51% of respondents have only partial or limited visibility and suspect there are Java instances they cannot see; 19% said 90% or more of their Java runtime estate met the referenced threshold.[1] Azul reports that 66% lack a mandated, time-bound commitment for patching non-critical vulnerabilities, while 38% patch them on a “best effort” basis.[1] Faster and more frequent patching was named as the primary exposure-reduction strategy by 32%, and better software and runtime visibility by 26%.[3]