162 vulnerabilities disclosed in Java's top 10 libraries

A new analysis from the Safeguard Research Team, published today, puts a hard number on a problem most Java shops have felt but never quantified: 162 distinct vulnerabilities, each with its own CVE, were disclosed across the ten most-downloaded Java libraries on Maven Central between January 1 and June 30, 2026. That figure spans foundational infrastructure — Apache Tomcat, the Spring Framework, Apache Commons, Netty, Jackson, Hibernate, Log4j2, Apache HttpClient, SnakeYAML, and Guava — the libraries that sit, often invisibly, inside nearly every enterprise Java application built in the last decade. Nineteen of the 162 were rated Critical (CVSS 9.0+), and Safeguard's telemetry indicates at least eleven were being actively probed in the wild within 30 days of public disclosure. It's a useful reminder that SCA vulnerabilities in widely-reused open source libraries scale differently than vulnerabilities in code you wrote yourself — one disclosure against a popular dependency can instantly affect thousands of downstream applications at once.

The report is not an indictment of any single project. Rather, it's a data point about scale: the Java ecosystem's most trusted, most widely reused components are also its largest concentrated attack surface, and the rate of disclosure against them is not slowing down.

The Numbers Behind the Report

Safeguard's research methodology pulled CVE records from NVD, GitHub Security Advisories, and vendor-published advisories, cross-referenced against Maven Central download rankings to identify the ten Java libraries with the highest aggregate weekly pull volume. The resulting distribution:

The remaining 85 disclosures were split between Medium (71) and Low (14) severity. That severity curve is worth sitting with: more than 47% of all disclosures landed at High or Critical, a noticeably steeper distribution than the roughly 35% High/Critical share Safeguard's researchers observed across the broader Maven Central corpus over the same period. Popularity, in other words, correlates with more scrutiny — and more scrutiny is surfacing more serious bugs, not just more noise.

Where the Risk Concentrates

Three patterns stand out in the classes of vulnerabilities behind these 162 CVEs.

Deserialization and injection remain the dominant primitive. Nearly a third of the High/Critical findings trace back to unsafe deserialization, XML/YAML parsing, or expression-language evaluation — the same vulnerability family that produced Log4Shell in 2021 and the Spring4Shell incident in 2022. SnakeYAML's continued exposure to constructor-based deserialization attacks, and a fresh round of Jackson polymorphic-typing gadget chains, show that this class of bug has not been engineered out of the ecosystem; it has just moved between libraries.

Servlet-container and framework-boundary bugs cluster in Tomcat and Spring. Tomcat's 24 disclosures and Spring's 22 together account for over a quarter of the total, and a disproportionate share involve request-smuggling, path-traversal, or authentication-bypass conditions at the boundary between the container and application code — exactly the layer most SCA tools have the weakest visibility into, because the vulnerable code path is often only reachable through specific configuration combinations.

Utility libraries are the quiet majority. Apache Commons and Guava rarely make headlines, but Commons alone contributed 21 CVEs this half — more than Log4j2 and SnakeYAML combined. These libraries are transitive dependencies more often than direct ones, pulled in by dozens of other frameworks, which means a single fix upstream can still leave an application vulnerable for months if the outdated version is buried three or four layers deep in the dependency tree.

The Disclosure-to-Patch Gap

Safeguard's telemetry from customer environments adds a second, more troubling dimension to the raw CVE count: time-to-remediation. Across the 19 Critical findings in this dataset, the median time between patch availability and enterprise deployment of that patch was 41 days. For the subset of organizations still running Java 8 or Java 11 on unsupported application servers, that number stretched past 90 days — well inside the window in which Safeguard observed opportunistic scanning activity targeting the same CVEs.

This gap is not primarily a patching-discipline problem. It's a visibility problem. Most of these 162 CVEs live in transitive dependencies that never appear in a pom.xml or build.gradle file directly — they're pulled in by Spring Boot starters, Hibernate's dependency graph, or Tomcat's embedded distribution. Security teams scanning only declared, top-level dependencies systematically undercount their real exposure, sometimes by a factor of five or more, because standard dependency manifests simply don't enumerate what's actually being loaded onto the classpath at build time.

Why This Matters Beyond the CVE Count

A raw vulnerability count is a blunt instrument. Not all 162 disclosures are equally dangerous to a given application, because not every vulnerable code path is actually reachable from an organization's own code. A Critical deserialization bug in a Jackson feature your application never enables poses effectively zero real-world risk; a Medium-severity path-traversal bug in a Tomcat handler your application exposes to the internet can be far more urgent. The report's most actionable finding, in that sense, isn't the 162 — it's the reminder that severity scores alone cannot tell a security team where to spend its next sprint. Exploitability in the abstract and exploitability in your specific deployment are frequently two different numbers.

That distinction is exactly what separates organizations that treated this half-year's disclosures as background noise from those that treated a handful of them as genuine fire drills. The libraries in this report aren't going anywhere — Tomcat, Spring, and Commons will still be running in production a decade from now — which means the recurring question for every Java-shipping organization isn't "are we vulnerable to CVE-XXXX," it's "how quickly can we find out, and how quickly can we act."

What Security Teams Should Take From This

For teams running Java at any meaningful scale, three actions follow directly from this data:

• Inventory transitive dependencies, not just direct ones. If your SBOM or SCA tool only reflects declared dependencies, you are almost certainly missing a majority of the 162 libraries and versions analyzed in this report as they actually exist in your running applications — and undercounting your real SCA vulnerabilities exposure as a result.
• Prioritize by reachability, not CVSS alone. With 19 Critical and 58 High disclosures competing for attention in a single half-year, teams that triage strictly by base severity score will burn cycles on unreachable findings while exploitable Medium-severity issues in exposed code paths go unaddressed.
• Shrink the patch-availability-to-deployment window. The 41-day median gap for Critical fixes is the single biggest lever most organizations have to pull, and it's largely an automation problem, not a resourcing one.

How Safeguard Helps

Safeguard is built to close exactly this gap. Our reachability analysis traces every one of these disclosed CVEs — including the ones buried in transitive dependencies four layers deep — against your actual call graph, so teams can see immediately which of the 162 vulnerabilities are truly exploitable in their codebase versus theoretical. Griffin AI, Safeguard's autonomous triage engine, correlates that reachability data with exploit intelligence and business context to rank remediation work by real-world risk rather than CVSS score alone. Continuous SBOM generation and ingest give security and engineering teams a live, accurate inventory of every Tomcat, Spring, Commons, and Jackson component actually running in production, not just what's declared in a manifest. And when a fix is confirmed safe, Safeguard's auto-fix PRs open the dependency bump directly against the affected repository, cutting that 41-day median patch-deployment window down to hours. For security teams trying to turn a report like this one from a quarterly anxiety spike into an operational, repeatable process, that's the difference that matters.