CVE-2026-93491 in Netty
Summary
by MITRE • 09/18/2026
A flaw was found in Netty's HttpServerCodec. A remote, unauthenticated attacker can exploit this vulnerability by pipelining HTTP/1.1 requests on a single connection and withholding reads. This action causes the methodOverflowQueue to grow without limit, leading to unbounded heap memory consumption and a denial of service due to memory exhaustion.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The identified vulnerability resides within Netty's HttpServerCodec component, specifically affecting how HTTP/1.1 request pipelining is managed on persistent connections. This flaw allows for a remote, unauthenticated denial-of-service attack by exploiting the interaction between request processing and read operations. In an HTTP/1.1 environment, clients are permitted to send multiple requests over a single TCP connection without waiting for individual responses, a feature known as request pipelining. The vulnerability arises when an attacker sends these pipelined requests but deliberately withholds reading any of the server's responses. This specific behavior triggers a flaw in how Netty buffers incoming data and manages internal queues during the decoding process.
Technically, the issue centers on the methodOverflowQueue within the HttpServerCodec implementation. When requests are pipelined, they must be buffered until the previous request has been fully processed and responded to. However, due to the logic flaw in this specific codec version, if the application does not consume or read from the connection promptly, the internal queue responsible for holding these pending method objects grows without limit. Instead of applying backpressure mechanisms that would slow down or disconnect the client when buffers reach a certain threshold, the system continues to allocate memory for each incoming request header and associated metadata. This results in unbounded heap memory consumption on the server side as long as the connection remains open and requests continue to arrive.
The operational impact of this vulnerability is severe, leading directly to resource exhaustion and service disruption. As the methodOverflowQueue expands indefinitely, it consumes increasing amounts of Java heap space allocated to the Netty event loop thread or associated worker threads. Eventually, the server process will encounter an OutOfMemoryError, causing the application to crash or become unresponsive. This constitutes a classic denial-of-service scenario where availability is compromised without requiring any authentication credentials from the attacker. The attack vector is particularly dangerous because it can be executed by automated tools that simply open connections and flood them with pipelined requests while ignoring responses, making detection based on user behavior difficult for standard web application firewalls that do not inspect deep packet states or connection lifecycle management closely enough.
From a classification perspective, this vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, specifically manifesting as memory exhaustion. It also relates to CWE-770, allocation of resources without limits or throttling, within the context of network connections and buffer handling. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is consistent with techniques used in denial-of-service attacks where an adversary aims to degrade service availability by exhausting system resources rather than compromising confidentiality or integrity. The lack of authentication requirements places it firmly in the remote attack vector category, lowering the barrier for exploitation significantly compared to authenticated vulnerabilities.
Mitigation strategies must focus on both immediate patching and architectural hardening. The primary remediation is to upgrade Netty to a version that includes fixes for this specific buffer management logic in HttpServerCodec. Organizations should verify their dependency trees using tools like OWASP Dependency-Check or Snyk to ensure no legacy versions of Netty are present in production environments. Beyond patching, implementing rate limiting and connection throttling at the network perimeter can help mitigate the impact by preventing a single client from overwhelming server resources with excessive pipelined requests. Additionally, configuring HTTP/1.1 keep-alive timeouts appropriately ensures that idle or abusive connections are terminated after a reasonable period of inactivity, thereby reducing the window of opportunity for such memory exhaustion attacks. Application-level monitoring should also be enhanced to track heap usage trends and connection states, allowing for early detection of anomalous resource consumption patterns indicative of this type of abuse.