High priorityDisclosed

Advisory · CVE-2026-100656

Netty HttpServerCodec can be drowned by a single pipelined connection

Netty's HttpServerCodec tracks the HTTP method of each still-unanswered pipelined request in an unbounded queue. A remote, unauthenticated attacker who pipelines HTTP/1.1 requests on one connection while withholding reads can grow that queue without bound, exhausting heap and denying service. Fixed in 4.1.138.Final and 4.2.18.Final.

Advisory published September 26, 2026Independent summary
Vendor
Netty
Product
Netty
Identifier / CWE
CVE-2026-100656
CWE-770
Action timing
Immediate
ELI5

Explain it like I’m five

The server keeps a to-do list of incoming requests, but the list has no bottom. An attacker keeps adding items without ever letting the server cross any off, until the list itself fills the whole room.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Pipelined requests

    The attacker opens one connection and pipelines many HTTP/1.1 requests.

  2. 02Withheld reads

    The attacker never reads the responses, so the server cannot flush and free state.

  3. 03Unbounded queue

    Each unanswered request's HTTP method is appended to methodOverflowQueue with no size limit.

  4. 04Heap exhaustion

    Heap grows without bound until the JVM throws OutOfMemoryError and the service dies.

What happened

Netty’s HttpServerCodec appends the HTTP method of every still-unanswered pipelined request to an unbounded methodOverflowQueue, and the queue is drained only when a flush sends the response (CVE-2026-100656, CVSS 8.7). A remote, unauthenticated attacker can pipeline HTTP/1.1 requests on a single connection and never read responses, so each send appends without any flush draining the queue, growing it without bound until the JVM throws OutOfMemoryError. The attack requires only TCP reachability to an HTTP/1.1 endpoint, no authentication and no special payloads. The issue is fixed in Netty 4.1.138.Final and 4.2.18.Final.

What to do

  1. Upgrade Netty to 4.1.138.Final or 4.2.18.Final (matching your 4.1 or 4.2 branch).
  2. Review dependency trees (transitive Netty use is common via frameworks) and upgrade where the HTTP codec is on the path.
  3. Watch heap metrics for unexplained growth on HTTP endpoints; this attack leaves little log evidence beyond eventual OOM.
  4. Consider connection-level request caps and aggressive read timeouts as defense in depth.

Management note

One connection, no credentials, no payload: this is about as cheap a denial-of-service as it gets against any Java HTTP stack built on Netty. Inventory Netty versions across services rather than assuming only your edge proxies matter.