Netty EUVD-2026-82930

Exploitation requires the target to be a Netty-based service that actively accepts and parses the PROXY protocol v2 - i.e., a listener configured with Netty's HAProxyMessageDecoder, typically because the app sits behind a load balancer/proxy that prepends PROXY headers. The attacker must be able to send raw connections to that PROXY-aware port. No authentication or user interaction is needed (PR:N/UI:N) and default parsing of untrusted PROXY-v2 frames is sufficient once the decoder is enabled. Limiting factors: services that do NOT enable PROXY-protocol handling are not exposed via this path, and impact is availability-only (no data compromise). Note this is described as an incomplete fix of PR #16881, so partially-patched deployments may remain vulnerable through the nested/grandchild-TLV code path.

This is a genuine but not top-tier availability issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) describes a remote, unauthenticated, low-complexity denial-of-service with pure availability impact and no confidentiality or integrity loss - consistent with a ByteBuf reference-count (memory) leak that, over many crafted PROXY-v2 frames, drives OOM/heap exhaustion. Despite 'HAProxy' in the title, the ByteBuf primitive and the PR reference indicate this is Netty's HAProxyMessageDecoder, and all affected CPEs are Red Hat Java middleware that bundle Netty, not the HAProxy load balancer itself. No EPSS score, no CISA KEV entry, and no public exploit are present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The description flags this as an INCOMPLETE FIX of PR #16881, which is a meaningful risk amplifier - the original patch left a nested/grandchild-TLV path unguarded, so environments that believed they were remediated may still be exposed. The input tag 'Information Disclosure' conflicts with the C:N/I:N/A:H vector and appears mislabeled; treat this as a DoS, not a data-exposure issue. Net: a real priority only for services that actually terminate the PROXY protocol on an internet-reachable listener; otherwise moderate.

An attacker who can reach a Netty-based service that accepts and parses PROXY-protocol v2 connections (e.g., an application configured to trust a fronting load balancer) opens connections and sends crafted PROXY-v2 headers containing nested TLVs whose grandchild ByteBuf is never released. Repeated over many connections, the leaked buffers accumulate on the heap until the JVM exhausts memory and the service degrades or crashes. No authentication or user interaction is required (PR:N/UI:N), though no public PoC is referenced in the available data.