Spring Boot Managed Dependencies Still Get CVEs After EOL: June 2026 Patch Round-Up

In May, we counted 24 upstream CVEs across five Spring Boot managed dependencies. June’s Boot managed dependency updates delivered 18 CVEs in one release. Netty 4.1.135.Final is an explicit security release, and it patches everything from DNS cache poisoning to a silently disabled TLS hostname check. If your Spring Boot line is EOL, none of it reaches you unless someone puts it there.

‍

The Dependency-Management Problem, Briefly

The full explanation is in the May round-up, so here is the short version. The spring-boot-dependencies BOM pins specific versions of Netty, Tomcat, Jackson, the Neo4j Java Driver, Dropwizard Metrics, and dozens of other libraries. On a maintained Boot line, those pins advance with each patch release. On an EOL line, they freeze.

The upstream projects do not freeze with them.

Netty's June release is the clearest single-month demonstration of this we have seen yet. One dependency. One release. Eighteen CVEs, most of them rated high by the project.

‍

What Was Patched in June 2026

The June 2026 NES Spring Boot release advances four managed-dependency pins:

Two items in the Netty batch deserve separate attention because they change actual security posture rather than availability.

CVE-2026-45674 is the headline. Netty's DNS resolver accepted responses without verifying they came from the legitimate server, so an off-path attacker could redirect an application's outbound connections to a host they control. GHSA scored it 8.7; NVD scored it a flat 10.0. It ships alongside two related resolver flaws, CVE-2026-47691 (the same missing origin check applied to NS referral records) and CVE-2026-45673 (predictable transaction IDs plus a static UDP source port, enabling a Kaminsky-style attack). Together they form a complete cache-poisoning toolkit. And because Netty rides transitively inside Elasticsearch clients, gRPC, and most reactive Java stacks, plenty of teams are exposed without a direct Netty dependency anywhere in their build files.

CVE-2026-50010 is the quiet one. TLS hostname verification could end up unintentionally disabled, which removes the check that a presented certificate actually belongs to the host being contacted. Nothing crashes. Nothing logs. The connection just stops proving it is talking to who it thinks it is.

‍

Not Every Bump Is a Security Fix, and That Is Fine

Three of the four bumps this month carry zero CVEs. That is not wasted work.

Netty 4.1.134.Final is a plain bug-fix release: a mistakenly removed HttpProxyHandler constructor restored, HTTP version and multipart header case folding pinned to a stable locale, a concurrency fix in the adaptive allocator. The Neo4j Java Driver 4.4.24 and Dropwizard Metrics 4.2.39 bumps are the same category. Staying current on patch releases is what keeps the eventual security bump a one-line diff instead of a multi-version leap with behavioral surprises in the middle.

But one of these hygiene bumps hides a detail worth knowing.

‍

The Shaded-Dependency Blind Spot

The Neo4j Java Driver 4.4 line ships its own shaded copy of Netty inside the driver jar. Driver 4.4.24 was tagged June 1, 2026. Netty 4.1.135.Final landed June 2. So the driver version in this month's BOM cannot contain the 18 security fixes described above, no matter what your dependency tree says about the standalone Netty artifacts.

This matters for two reasons. First, shaded classes are relocated under the driver's own package namespace, and many SCA scanners never see them. Your dashboard can show a clean Netty 4.1.135 while a vulnerable copy sits inside another jar. Second, the fix window is real but easy to miss: Neo4j shipped 4.4.25 on June 23 with further dependency updates, so teams tracking the shaded copy need to verify which driver patch actually picks up 4.1.135.

This is exactly the kind of second-order tracking that disappears from view when a Boot line goes EOL and nobody owns the dependency graph anymore.

‍

The Self-Managed Override Burden

The May round-up walks through the full nine-step workflow a team takes on for every upstream CVE when self-managing overrides on an EOL Boot line: advisory monitoring, version-range matching, override authoring, BOM compatibility validation, regression testing, and the evidence artifacts that security and audit teams expect.

June's math is simpler and harsher. Eighteen CVEs, one dependency, one month. The monitoring burden did not shrink because the CVEs concentrated in one project. It just means one missed release note now costs eighteen findings on the next scan instead of one.

‍

How NES Handles This Work

The HeroDevs Spring engineering team runs the same workflow on the NES side. The June 2026 release picks up the 18 Netty CVEs at 4.1.135.Final, carries the intermediate 4.1.134.Final fixes, and advances the Neo4j Java Driver and Dropwizard Metrics pins, then publishes the result as patched Boot artifacts at the original Maven and Gradle coordinates your builds already reference.

What your team does not have to do:

• Watch upstream advisories across every managed dependency in the BOM.
• Match affected version ranges against frozen BOM pins, including shaded copies.
• Author overrides and validate them against Boot's dependency resolution.
• Regression test the affected application surface.
• Produce release notes, advisory analysis, and version manifests for audit evidence.

NES does not eliminate code changes in every environment. What it does is collapse the dependency-bump workflow into the release cadence you already run.

‍

Taking Action

For teams currently running an EOL Spring Boot line, three practical steps:

1. Inventory the applications running each Boot line. The HeroDevs EOL Discovery Scanner produces this automatically, including the Boot version each application actually consumes.
2. Find your Netty exposure. Reactive and WebFlux workloads are the obvious surface, but check for Netty arriving transitively through gRPC, Elasticsearch clients, Cassandra drivers, and shaded copies inside other jars. The DNS resolver CVEs apply to anything using netty-resolver-dns.
3. Decide whether to self-manage overrides or use NES. If your team can absorb the monitoring and validation workload at the cadence upstream projects ship, the self-managed path is real. If that capacity should be going to product work, NES for Spring delivers these bumps on the Maven and Gradle workflow you already use.

‍

Related Reading

• Spring Boot Managed Dependencies Still Get CVEs After EOL: May 2026 Patch Round-Up, HeroDevs. The previous entry in this series.
• Spring Boot Versions, EOL Dates, and Latest Releases, HeroDevs. The foundational EOL reference.
• The Hidden Risk in Spring Boot 2.7: Managed Dependencies Still Matter, HeroDevs. Prior coverage of managed-dependency drift.
• Netty 4.1.135.Final release announcement, netty.io, June 2, 2026.

‍

Appendix: Full CVE List with Advisory Links

Every CVE fixed in Netty 4.1.135.Final, organized by affected module, with severity and a one-sentence description. Severity labels follow the Netty release announcement and GitHub advisories. Useful for SCA tool reconciliation and evidence collection.

DNS resolver (netty-resolver-dns)

• CVE-2026-45674 (High, GHSA 8.7 / NVD 10.0): DNS responses were cached without verifying they came from the legitimate server, letting an off-path attacker redirect the application's traffic to a host they control.
• CVE-2026-47691 (High, CVSS 8.6): The same missing origin check applied to NS referral records, so an attacker can substitute a fake referral server and control every subsequent lookup under that domain.
• CVE-2026-45673 (Moderate, CVSS 6.8): Predictable transaction IDs from a weak PRNG combined with a static default UDP source port reduced DNS query entropy enough to enable Kaminsky-style cache poisoning.

TLS and connection filtering (netty-handler)

• CVE-2026-50010 (High): TLS hostname verification could be unintentionally disabled, removing the check that a presented certificate matches the host being contacted.
• CVE-2026-44249 (High): IpSubnetFilter rules could be bypassed for IPv6 traffic, admitting connections the filter was configured to reject.
• CVE-2026-45416 (High): SNIHandler could be driven into excessive memory usage by crafted TLS handshake data.

HTTP and HTTP/2 (netty-codec-http, netty-codec-http2)

• CVE-2026-50020: A parsing flaw in the HTTP/1 codec enables request smuggling.
• CVE-2026-50560: A flaw in the HTTP/2 codec can be abused for distributed denial of service.
• CVE-2026-47244: Denial of service in the HTTP/2 codec.
• CVE-2026-48043: Memory exhaustion in the HTTP/2 codec.

Redis codec (netty-codec-redis)

• CVE-2026-50011 (High): Memory exhaustion reachable through crafted Redis protocol input.
• CVE-2026-44250 (High): Memory exhaustion reachable through crafted Redis protocol input.
• CVE-2026-44890 (High): Memory exhaustion reachable through crafted Redis protocol input.
• CVE-2026-48006 (High): Memory exhaustion reachable through crafted Redis protocol input. The release also bounds nested array depth in RedisArrayAggregator and correctly releases incomplete messages on removal.

HAProxy PROXY protocol codec (netty-codec-haproxy)

• CVE-2026-48059 (High): PROXY protocol v2 headers carrying nested PP2_TYPE_SSL records at depth two or greater leak native or heap memory on every connection.
• CVE-2026-44893 (High, CVSS 7.5): A record with an undersized length field triggers an uncaught exception after a buffer slice has been retained, and the slice is never released, leaking pooled memory.

Transports (netty-transport-sctp, netty-transport-native-epoll, netty-transport-native-kqueue)

• CVE-2026-46340 (High): Memory exhaustion in the SCTP transport.
• CVE-2026-45536 (Moderate): Receiving two file descriptors in a single message over a Unix domain socket leaks both descriptors in the native epoll and kqueue transports; requires opting into file-descriptor read mode.