CVE-2026-93491: Netty HttpServerCodec DOS Vulnerability

CVE-2026-93491 Overview

CVE-2026-93491 is a denial of service vulnerability in Netty's HttpServerCodec. A remote, unauthenticated attacker can exploit the flaw by pipelining HTTP/1.1 requests on a single connection while withholding reads on the client side. The server's methodOverflowQueue grows without limit, driving unbounded heap memory consumption and eventual memory exhaustion. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling]. Fixed releases are available in netty-4.1.138.Final and netty-4.2.18.Final. Red Hat has published advisories RHSA-2026:69440, RHSA-2026:69470, and RHSA-2026:70257 covering affected downstream products.

Critical Impact
A single unauthenticated TCP connection can exhaust JVM heap memory on any HTTP service built with vulnerable Netty versions, taking the process offline.

Affected Products

Netty framework versions prior to 4.1.138.Final (4.1.x branch)
Netty framework versions prior to 4.2.18.Final (4.2.x branch)
Red Hat products referenced in advisories RHSA-2026:69440, RHSA-2026:69470, and RHSA-2026:70257

Discovery Timeline

2026-09-18 - CVE-2026-93491 published to the National Vulnerability Database
2026-09-22 - CVE-2026-93491 last modified in NVD

Technical Details for CVE-2026-93491

Vulnerability Analysis

Netty's HttpServerCodec combines the request decoder and response encoder for HTTP/1.1 traffic. To correctly encode responses for HEAD and CONNECT requests, the codec queues the HTTP method of each inbound request in an internal structure named methodOverflowQueue. Under normal conditions, entries are removed as responses are written back to the client.

When an attacker pipelines many HTTP/1.1 requests on a single TCP connection and refuses to read responses, TCP backpressure blocks the server's writes. Requests continue to be decoded because Netty reads from the socket independently of write progress. Each new request adds an entry to methodOverflowQueue, which has no upper bound. Heap usage grows until the JVM terminates with OutOfMemoryError or garbage collection thrashing renders the service unresponsive.

The flaw requires no authentication, no user interaction, and no special protocol features beyond standard HTTP/1.1 pipelining. Any Netty-based HTTP server exposed to untrusted clients is at risk.

Root Cause

The root cause is missing throttling on the methodOverflowQueue data structure within HttpServerCodec. The queue is populated on every decoded request but only drained on response emission, so a client that stalls response reads breaks the invariant that ties queue growth to request processing rate.

Attack Vector

Exploitation is entirely network-based. An attacker opens a TCP connection to a vulnerable HTTP endpoint, sends a continuous stream of pipelined HTTP/1.1 requests, and stops reading from the socket. The attack scales with the amount of memory the JVM is allowed to allocate and requires only modest bandwidth from the attacker. The vulnerability description and technical details are documented in the Red Hat CVE entry for CVE-2026-93491 and Red Hat Bug Report #2536891.

Detection Methods for CVE-2026-93491

Indicators of Compromise

Sustained heap growth on Netty-based JVM processes without a corresponding increase in completed request counts.
Long-lived TCP connections with large receive-side queues on the server and near-zero bytes read by the client.
Repeated java.lang.OutOfMemoryError: Java heap space events referencing io.netty.handler.codec.http.HttpServerCodec or methodOverflowQueue in stack traces.
Spikes in pipelined HTTP/1.1 requests from a single source IP with no matching response acknowledgements.

Detection Strategies

Instrument JVM metrics such as jvm.memory.used, HeapMemoryUsage, and GC pause time; alert on sustained growth without traffic volume increases.
Correlate application logs with connection-level metrics to flag connections that decode many requests but produce few responses.
Inventory application dependencies to identify Netty versions below 4.1.138.Final and 4.2.18.Final, including transitive dependencies pulled in by frameworks such as Vert.x, gRPC-Java, Spring WebFlux, and Elasticsearch clients.

Monitoring Recommendations

Enable per-connection metrics in Netty using ChannelTrafficShapingHandler or equivalent to observe read/write imbalance.
Forward JVM and reverse-proxy logs to a centralized analytics platform for correlation across hosts.
Track connection duration and request-per-connection distributions to baseline normal pipelining behavior and detect deviations.

How to Mitigate CVE-2026-93491

Immediate Actions Required

Upgrade Netty to 4.1.138.Final on the 4.1.x branch or 4.2.18.Final on the 4.2.x branch as documented in the Netty 4.1.138.Final release notes and Netty 4.2.18.Final release notes.
For Red Hat customers, apply the packages published in RHSA-2026:69440, RHSA-2026:69470, and RHSA-2026:70257.
Audit shaded or bundled copies of Netty inside application JARs and container images to ensure the fixed version is actually loaded at runtime.

Patch Information

The upstream fix is included in Netty 4.1.138.Final and 4.2.18.Final. The patched HttpServerCodec bounds the growth of the internal method-tracking queue so that a stalled client cannot force unbounded heap allocation. Downstream fixes for Red Hat products are enumerated in the referenced RHSA advisories.

Workarounds

Place a reverse proxy such as HAProxy, NGINX, or Envoy in front of Netty-based services and limit HTTP/1.1 pipelining depth and per-connection request rates.
Configure idle and write timeouts using IdleStateHandler so connections that stop reading responses are closed before memory pressure builds.
Constrain JVM heap size and enable container-level memory limits so a compromised process fails fast rather than degrading a shared host.
Restrict exposure of Netty-based management or internal HTTP endpoints to trusted networks until patches are applied.

bash

# Example Maven dependency override to force the patched Netty version
# pom.xml
# <dependencyManagement>
#   <dependencies>
#     <dependency>
#       <groupId>io.netty</groupId>
#       <artifactId>netty-bom</artifactId>
#       <version>4.1.138.Final</version>
#       <type>pom</type>
#       <scope>import</scope>
#     </dependency>
#   </dependencies>
# </dependencyManagement>

# Verify the resolved Netty version at build time
mvn dependency:tree -Dincludes=io.netty