CVE-2026-48059: Netty Information Disclosure Vulnerability

CVE-2026-48059 Overview

CVE-2026-48059 is a memory leak vulnerability [CWE-401] in Netty, a network application framework widely used for building protocol servers and clients in Java. The flaw resides in the HAProxy PROXY protocol v2 codec. Versions prior to 4.1.135.Final and 4.2.15.Final leak native or heap memory on every connection where a client transmits a syntactically valid header containing nested PP2_TYPE_SSL type-length-value (TLV) records at depth two or greater. Each affected connection permanently pins a pooled ByteBuf, enabling remote attackers to exhaust server memory without authentication.

Critical Impact
Unauthenticated remote attackers can exhaust JVM heap or native memory on Netty-based servers using the HAProxy PROXY v2 codec, leading to denial of service.

Affected Products

Netty netty versions prior to 4.1.135.Final
Netty netty versions prior to 4.2.15.Final
Applications and proxies embedding the Netty HAProxy PROXY protocol v2 codec

Discovery Timeline

2026-06-12 - CVE-2026-48059 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-48059

Vulnerability Analysis

The vulnerability resides in Netty's HAProxy PROXY protocol v2 decoder. The PROXY v2 specification permits TLV records, including PP2_TYPE_SSL, which itself contains nested sub-TLVs describing TLS metadata. The decoder correctly parses headers when these PP2_TYPE_SSL records appear at the top level of the TLV section.

When PP2_TYPE_SSL records are nested at depth two or greater, parsing still succeeds, the resulting HAProxyMessage propagates downstream, and the decoder removes itself from the pipeline as designed. The application then releases the HAProxyMessage reference normally. However, the cumulation ByteBuf allocated by the channel, frequently a pooled and potentially direct buffer, is never released back to the allocator.

Every connection carrying this header shape pins memory permanently. Because PROXY v2 typically fronts load balancers and reverse proxies, attackers can open large numbers of connections to drive memory consumption until the JVM throws OutOfMemoryError or the host exhausts native memory.

Root Cause

The root cause is an unreleased reference to the cumulation buffer on the successful parse path through nested PP2_TYPE_SSL TLVs. The decoder's reference counting omits a release call when recursion through nested SSL sub-TLVs completes, leaving the pooled ByteBuf retained in the pool's bookkeeping yet detached from any usable handle.

Attack Vector

Attackers reach the vulnerable code path over the network without authentication or user interaction. Any service that terminates connections behind a Netty-based HAProxy PROXY v2 listener is exposed. The attacker constructs a syntactically valid PROXY v2 header containing at least one PP2_TYPE_SSL TLV that itself encloses additional PP2_TYPE_SSL records, then disconnects and reconnects to amplify the leak.

No exploitation code is required to be uploaded. The vulnerability is described in prose; refer to the GitHub Security Advisory GHSA-h2qv-fj59-j46j for the precise TLV structure and patched parsing logic.

Detection Methods for CVE-2026-48059

Indicators of Compromise

Steadily rising JVM heap, direct buffer, or native memory usage on services exposing the Netty HAProxy PROXY v2 codec, uncorrelated with traffic volume.
io.netty.buffer.PoolArena metrics showing increasing active allocations without corresponding releases.
Repeated short-lived TCP connections from a small set of source addresses targeting PROXY v2 listeners.
OutOfMemoryError: Direct buffer memory or container OOM-kill events on otherwise stable Netty workloads.

Detection Strategies

Enable Netty's ResourceLeakDetector at PARANOID level in non-production and ADVANCED in production to surface unreleased ByteBuf instances tied to HAProxyMessageDecoder.
Inventory deployed Netty artifacts and flag any netty-codec-haproxy JAR with a version below 4.1.135.Final or 4.2.15.Final.
Capture and inspect PROXY v2 headers at ingress points for PP2_TYPE_SSL TLVs containing nested PP2_TYPE_SSL sub-records.

Monitoring Recommendations

Track JVM heap, direct memory, and jemalloc/glibc resident set size with alerts tuned for monotonic growth on long-lived services.
Export Netty allocator metrics (PooledByteBufAllocatorMetric) to Prometheus or an equivalent backend and alert on sustained increases in numActiveAllocations.
Use Singularity Endpoint behavioral telemetry to correlate process-level memory anomalies with inbound network connections targeting PROXY v2 ports.

How to Mitigate CVE-2026-48059

Immediate Actions Required

Upgrade netty-codec-haproxy and transitive Netty dependencies to 4.1.135.Final or 4.2.15.Final across all environments.
Audit dependency trees with mvn dependency:tree or gradle dependencies to confirm no shaded or relocated Netty copies remain on a vulnerable version.
Restart affected JVM processes after upgrade to release pinned cumulation buffers.

Patch Information

The Netty maintainers fixed CVE-2026-48059 in Netty 4.1.135.Final and Netty 4.2.15.Final. The patches ensure the cumulation ByteBuf is released on every parse path, including when nested PP2_TYPE_SSL TLVs are encountered. Full technical details are documented in the GitHub Security Advisory GHSA-h2qv-fj59-j46j.

Workarounds

Terminate PROXY v2 traffic in front of Netty with a non-Netty proxy (e.g., HAProxy itself) that strips or rejects nested PP2_TYPE_SSL TLVs.
Restrict PROXY v2 acceptance to trusted load balancer source addresses using network ACLs or firewall rules.
Disable the PROXY protocol listener entirely if upstream infrastructure does not require it until the upgrade is deployed.

bash

# Configuration example: enforce patched Netty version via Maven
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.1.135.Final
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.2.15.Final
mvn dependency:tree | grep -E 'netty-(codec-haproxy|all|common)'