This year brought a record 5,649 Java security flaws. Attackers have used 18.

The surge in flaws did not bring a surge in attacks #

Between 1 January and 1 November, 5,649 security flaws were published for Java software. That is more than five times as many as in the same months of 2025. In no earlier year did those months produce even a fifth as many.

The number of new Java flaws attacked had risen every year since 2021. By 1 November 2024, attackers had exploited 10 of that year's flaws. By the same date in 2025, the number had nearly doubled, to 19.

This year's surge did not push it higher. By 1 November, attackers had exploited 18 of the flaws published in 2026.

Most of the new flaws are Oracle's #

Until this year, Java had no part in the CVE boom. Worldwide, the number published each year nearly tripled between 2018 and 2025, to 48,151. Java's yearly count barely moved.

The 2026 surge comes mostly from Oracle. Its products account for 3,659 of this year's Java CVEs. In all of 2025, they accounted for 165. Java CVEs from other vendors have grown too, but more slowly than CVEs overall.

Severity scores measure harm, not the odds of attack #

Most organisations decide what to patch by CVSS score. The score estimates the harm a flaw could cause. It does not estimate the chance that anyone will exploit it.

The usual cut-off is 7.0, the line between medium and high. Patching every Java CVE at or above it means 8,648 flaws, half the total. That covers 238 of the 288 that attackers have exploited. It misses the other 50, about one in six. Move the line to test a different policy.

A much shorter list that catches almost as many attacks #

There is a better place to start. Public exploit code, published in catalogues such as Exploit-DB and Metasploit or shared on GitHub, exists for 691 Java CVEs. That is fewer than one in 25.

Those 691 include 230 of the 288 Java CVEs attacked in the wild, four in every five. Patching everything scored 7.0 or higher catches 238, but the list is twelve times as long.

Sometimes the attack comes first and the published code follows. That happened with 35 of the 230. In the other 195, the code was public before any recorded attack.

Exploit code is also a sharper signal in Java than across software as a whole. One in three Java CVEs with public exploit code has been attacked. For all other CVEs, the rate is one in ten.

Much of the difference lies in who the code is written for. Nearly three in four Java exploits target products from the largest vendors, those with 1,000 or more CVEs on record, such as Oracle and Apache. Outside Java, almost half target vendors with fewer than ten CVEs. Attackers seldom use those: about one in 25 has been exploited in the wild.

Vendor size does not explain all of it. Even among exploits for the largest vendors, those for Java products lead to attacks twice as often as the rest.

This year's flood has added almost nothing to the list. Of the 5,649 Java CVEs published in 2026, 36 have public exploit code. Oracle's products are mostly closed source. Just two of its 3,659 new Java CVEs have a public exploit.

Forecasts and catalogues miss most new attacks #

Many teams already look past the severity score, to EPSS forecasts and CISA's catalogue of exploited flaws. Both help. Neither saw most of last year's attacks coming.

CISA's catalogue lists 102 of the 288 Java CVEs with recorded attacks. It adds a flaw once attacks are confirmed, so it shows what has already been hit.

EPSS forecasts the chance of an attack in the next 30 days. A year before this report, on 1 November 2025, 766 Java CVEs with no recorded attack yet had a forecast of 10% or more. Over the following year, attackers were first recorded using 46 Java CVEs. The list included 11 of them. Eighteen had not been published when the forecast was made.

EPSS does best with old, well-known flaws, such as the Struts and WebLogic bugs attackers keep returning to. It does worst with new flaws in closed-source products. The day before attacks were first recorded on four Oracle CVEs this past year, EPSS gave each of them a chance of less than 1%.

Public exploit code picked out more of the 46. On 1 November 2025, code was public for 446 Java CVEs with no recorded attack yet. That list included 14 of them. The 446 highest EPSS forecasts that day included 9. No list drawn up that day could include the 18 flaws not yet published.

Three kinds of bug draw half the attacks #

Injection, deserialization and file-handling flaws let an attacker run code on a server or reach its files. Only 14% of Java CVEs are of these kinds. They account for 51% of the attacked ones.

Access-control flaws are the reverse. They make up almost half of Java CVEs but only about a quarter of those attacked.

Deserialization is a peculiarly Java problem. It accounts for 13% of attacked Java CVEs, more than four times its share elsewhere. Java made it easy to rebuild objects from incoming bytes. Attackers learned to craft bytes that run their commands during the rebuild.

Attackers return to the same projects #

Twelve projects account for 149 of the 288 Java CVEs that attackers have exploited, more than half. Those projects produced only a quarter of all Java CVEs.

Some are hit year after year. Every year from 2016 to 2025 produced at least one Oracle WebLogic Server flaw that was later attacked. Apache Struts has attacked flaws from twelve different years, the earliest from 2006.

In a few projects, the odds are far higher. Across Java, one CVE in 61 has been attacked. In Log4j, and in GeoServer and GeoTools, the rate is roughly one in three.

The JDK is the exception. All 29 of its attacked flaws were published between 2008 and 2016. None of the JDK flaws published since then has been attacked.

The JDK got safer. The libraries on top of it did not. #

A decade ago, attackers aimed at the Java runtime itself. Browser applets let any web page run code on a visitor's Java runtime. In 2013, Oracle's JDK and JRE had 177 CVEs. Browsers dropped the plugin, Oracle deprecated applets, and the count fell to 12 in 2025.

Meanwhile, the software built on Java produced more and more CVEs. CVEs in frameworks, application servers and other Java products, excluding Oracle's, rose from about 60 in 2010 to more than 900 a year in 2022 and 2023. This year there have been 1,990.

Attackers keep using old Java bugs #

Attackers tend to exploit what is new. Outside Java, half of the CVEs with attack evidence recorded in 2026 were two years old or less.

Java is different. Half of the Java CVEs attacked this year were 4.5 years old or more. More than two in five were published over five years ago, twice the share elsewhere. CISA's catalogue shows the same lag. Since 2023, 45% of the Java CVEs it added were more than a year old when listed. For other CVEs, the share was 21%. In October 2026 it added a Struts flaw published ten years earlier.