CVE-2026-59899

What it actually does

CVE-2026-59899 is a network-reachable denial-of-service flaw in Netty's HTTP content encoding path. In vulnerable versions before 4.1.136.Final and 4.2.16.Final, HttpContentEncoder and its common production subclass HttpContentCompressor maintain a per-connection acceptEncodingQueue that stores attacker-controlled Accept-Encoding-related request state without a size bound. When HTTP/1.1 pipelining is used, an attacker can send many requests over the same TCP connection faster than the application produces corresponding non-1xx responses. The queue grows on the I/O event loop thread and is only drained when responses are written, allowing a single or small number of connections to consume memory and event-loop capacity, potentially causing latency spikes, garbage-collection pressure, OutOfMemoryError conditions, dropped connections, or process termination.

Why it matters to the business

Successful exploitation can degrade or interrupt availability of services built on vulnerable Netty versions, especially public-facing HTTP services that allow HTTP/1.1 keep-alive/pipelining and use Netty's HTTP compression handler. The CVSS availability impact is low and EPSS is currently low, with no known KEV listing or public exploit maturity reported, but the vulnerability is recent and easy to reach over the network without authentication. For organizations with many Java services or downstream frameworks depending on Netty, the operational risk is amplified because the affected library may be embedded transitively in gateways, APIs, application servers, and microservices.

How an attack unfolds

An attacker identifies an HTTP endpoint backed by a vulnerable Netty version with HttpContentCompressor or a related HttpContentEncoder in the channel pipeline. The attacker opens one or more HTTP/1.1 keep-alive connections and sends a rapid stream of pipelined requests, typically including Accept-Encoding headers, without waiting for responses. Netty processes each inbound request on the I/O thread and records encoding negotiation data in the per-channel acceptEncodingQueue. If the application is slow to generate non-1xx responses, or the attacker sends requests faster than responses are produced, the queue grows without an enforced upper bound. Continued flooding increases heap usage and event-loop work, which can lead to high garbage collection, request latency, connection resets, application errors, or service unavailability.

How to fix it

Upgrade Netty to a fixed release: 4.1.136.Final or later for the 4.1.x line, or 4.2.16.Final or later for the 4.2.x line. Because Netty is often pulled in transitively by frameworks, inspect dependency trees and container images rather than only direct package declarations. If immediate upgrade is not possible, reduce exposure by disabling or limiting HTTP/1.1 pipelining where supported, enforcing strict per-connection request limits, lowering keep-alive request counts/timeouts, applying request-rate limits at a reverse proxy or load balancer, and disabling HTTP response compression on vulnerable Netty pipelines if operationally acceptable. Ensure mitigations are applied before traffic reaches the vulnerable Netty handler; application-level throttling after Netty parsing may not fully prevent queue growth.

How to confirm the fix worked

Confirm that all deployed Java artifacts resolve Netty versions at or above 4.1.136.Final or 4.2.16.Final. Validate with build dependency output such as Maven dependency:tree, Gradle dependencies/dependencyInsight, SBOM scans, container image scans, and runtime classpath inspection. Where feasible, confirm effective runtime versions by checking packaged JAR names, MANIFEST.MF implementation versions, or application startup dependency logs. Test edge controls by sending controlled HTTP/1.1 pipelined requests in a non-production environment and verifying that per-connection request limits, rate limits, or disabled pipelining prevent unbounded memory growth. Monitor after patching for absence of unusual heap growth, excessive GC, event-loop saturation, and repeated failures during pipelined request bursts.

Typical attack path

1. Scan or probe for HTTP services likely implemented with Netty or Netty-based frameworks.
2. Establish one or more HTTP/1.1 keep-alive connections to the target service.
3. Send a high volume of pipelined HTTP requests on each connection without waiting for responses.
4. Include Accept-Encoding headers so the HTTP content encoder/compressor tracks per-request encoding state.
5. Maintain request pressure faster than the application can write non-1xx responses.
6. Cause unbounded growth of the per-channel acceptEncodingQueue, increasing memory use and event-loop pressure.
7. Trigger service degradation, connection failures, application restarts, or denial of service.

How to detect it

To assess possible prior exploitation, review edge proxy, load balancer, WAF, web server, and application access logs for clients sending many HTTP/1.1 requests over the same keep-alive connection with little or no response pacing. Look for repeated requests from the same source and connection, unusually high request counts per connection, pipelined request behavior, frequent Accept-Encoding headers, abnormal 5xx responses, connection resets, and request bursts followed by service latency or restarts. On hosts and containers, review JVM logs, application logs, GC logs, APM traces, Kubernetes events, and system metrics for heap growth, long or frequent garbage collections, java.lang.OutOfMemoryError, Netty event-loop stalls, process restarts, or liveness/readiness probe failures during the same time windows. Because this vulnerability does not create a unique file or command artifact, detection is behavioral and should correlate network-layer pipelining patterns with JVM memory pressure and availability symptoms.

• java.lang.OutOfMemoryError
• OutOfMemoryError: Java heap space
• io.netty.handler.codec.http.HttpContentEncoder
• io.netty.handler.codec.http.HttpContentCompressor
• acceptEncodingQueue
• Accept-Encoding: gzip
• Accept-Encoding: br
• Accept-Encoding: deflate
• HTTP/1.1
• Connection: keep-alive
• Full GC
• GC overhead limit exceeded
• event loop blocked
• io.netty.channel.EventLoop
• ReadTimeoutException
• Connection reset by peer

What your security team should do

• Prioritize upgrading all Netty 4.1.x deployments to 4.1.136.Final or later and all Netty 4.2.x deployments to 4.2.16.Final or later.
• Inventory direct and transitive Netty usage across Java services, API gateways, reverse proxies, SDKs, and Netty-based frameworks.
• Identify internet-facing HTTP/1.1 services using Netty HTTP compression and treat them as highest priority for remediation or compensating controls.
• Temporarily enforce connection-level limits, request-rate limits, keep-alive request caps, and pipelining restrictions at edge proxies or load balancers.
• Consider disabling HTTP compression in vulnerable Netty pipelines until patched if service requirements allow.
• Add monitoring for sudden heap growth, OutOfMemoryError events, elevated garbage collection, event-loop latency, and high volumes of pipelined requests from the same source.
• Review recent availability incidents since publication for signs of request floods over long-lived HTTP/1.1 connections.
• Track vendor advisories for frameworks that bundle Netty and apply their patched releases as they become available.