CVE-2026-48006: Netty's Lack of Lifecycle Cleanup Leads to Pooled ByteBuf Leak in RedisArrayAggregator
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Metrics
- CVSS v4.0
- 8.7
- Severity
- HIGH
- Fixed in
- —
- Affected Products
- 1
HarborGuard Analysis
Synopsis
A resource-leak vulnerability in Netty's RedisArrayAggregator handler allows pooled direct-memory buffers to leak whenever a Redis pipeline connection closes before a RESP array response is fully assembled. The flaw is reachable over the network by any unauthenticated peer and requires no victim interaction. A remote attacker who repeatedly opens and closes connections can drain the JVM-wide direct-memory pool, eventually causing allocation failures across all Netty channels in the affected process. No fix versions have been published yet; HarborGuard tracks the advisory and will make a patched-image rebuild available as soon as upstream ships a fix.
HarborGuard Coverage
Detection of CVE-2026-48006 is available across every HarborGuard environment: the CVE is ingested from upstream advisory feeds within minutes of publication and matched against all customer images, including custom-built images that bundle Netty directly. Any image containing a vulnerable version of netty/netty in the affected ranges (>=4.2.0.Final and <4.2.15.Final, or <4.1.135.Final) will surface a finding in the relevant registry and pipeline scans.
AvailableTriage is available with the CVSS v4.0 score of 8.7 (HIGH) applied automatically, weighted against each customer organization's per-environment compliance policy to prioritize findings correctly. Routing to the appropriate team inbox within each customer org is handled by HarborGuard's policy engine based on image ownership and severity thresholds.
AvailableBecause no fix version has been published upstream, HarborGuard re-evaluates the advisory on every ingest cycle and will make a patched-image rebuild available the moment Netty versions 4.1.135.Final or 4.2.15.Final (or later) are confirmed as fixes. For customers with auto-remediation enabled, the rebuild, regression run, and PR against affected workloads will be triggered automatically at that point without requiring manual intervention.
Pending upstreamExploit Conditions
- Network reachabilityRequired
The vulnerable handler is exposed over the network; an attacker must be able to reach the Netty service to open and close Redis pipeline connections.
- AuthenticationNot required
No credentials are needed; any network peer can trigger the leak by initiating and closing connections.
- Victim interactionNot required
Exploitation is fully automated and requires no action from any user or operator of the affected service.
- Attack complexityDetail
The exploit is reliable and condition-free; repeatedly opening and closing connections is sufficient to drain the direct-memory pool without needing to satisfy any race condition or specific memory layout.
Blast Radius
- Repeated connection churn exhausts the JVM-wide direct-memory pool shared by all Netty channels in the process.
- Once the pool is drained, all new buffer allocations across every Netty channel in the same JVM fail, not just those handling Redis traffic.
- The affected service becomes unable to process any network I/O, resulting in a full service outage for the process.
- No confidential data is read and no stored data is modified; impact is limited to availability.
How HarborGuard Handles This
Available on HarborGuard: images containing affected Netty versions are flagged automatically within minutes of CVE ingestion, across both registry scans and active CI/CD pipeline checks. Because upstream has not yet published a patched release, HarborGuard monitors the advisory on every ingest cycle and will make a patched-image rebuild available the moment Netty 4.1.135.Final or 4.2.15.Final is confirmed as the fix; for customers with auto-remediation enabled, the rebuild, regression run, and PR will be opened against affected workloads without manual steps. In the interim, compensating controls available to consider include isolating affected services behind a network policy that restricts which peers can open Redis pipeline connections, applying egress filtering to limit connection-churn sources, and disabling the RedisArrayAggregator handler via feature-flag or configuration if the workload does not require Redis pipelining support.
- netty / netty>= 4.2.0.Final, < 4.2.15.Final · < 4.1.135.Final
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N