Description

Netty's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.0.Final through 4.2.17.Final retains unbounded per-stream QPACK encoder state. QpackEncoder stores a queue and a dynamic-table index tracker for every encoded field section that references the QPACK dynamic table, keyed by the peer-controlled QUIC stream ID, and these entries are released only when the remote decoder sends a Section Acknowledgment or Stream Cancellation instruction — not when the HTTP/3 stream completes. There is no limit on the number of tracked streams, field sections, or retained bytes. A remote, unauthenticated HTTP/3 client can advertise a non-zero QPACK dynamic-table capacity, acknowledge the table insertion so the server reuses a dynamically indexed response header, and then omit all mandatory Section Acknowledgments while issuing sequential requests over a single QUIC connection, bypassing concurrent-stream limits and causing unbounded heap growth until the server exhausts memory (denial of service). Fixed in 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:48.970Z",
  "pubdate": "2026-09-26T14:16:48.970Z",
  "executiveSummary": "The vulnerability is an unbounded resource consumption flaw within the io.netty:netty-codec-http3 component, classified as a Denial of Service (DoS) risk. The issue originates from improper state management of the QPACK (QPACK Header Compression) dynamic table tracker.\nAffected systems include Netty versions 4.2.0.Final through 4.2.17.Final. An unauthenticated remote attacker can exploit this by manipulating QPACK acknowledgement flows to force the server to retain unbounded amounts of data in its heap memory.\nThe impact is significant, as it allows a remote, unauthenticated client to exhaust the server's memory, leading to application instability or total system crash. This vulnerability bypasses standard concurrent-stream limitations, making it a potent vector for service disruption. Successful exploitation requires an attacker to initiate an HTTP/3 connection and perform specific, non-compliant QPACK signaling sequences to prevent state cleanup.\nThere are no complex prerequisites other than the ability to initiate HTTP/3 traffic to the vulnerable service. Organizations relying on the affected Netty codec should prioritize upgrading to version 4.2.18.Final to eliminate the underlying architectural flaw.",
  "technicalDetails": "The root cause of this vulnerability lies in the lifecycle management of the QpackEncoder state within the io.netty:netty-codec-http3 library. The encoder incorrectly binds the retention of per-stream QPACK encoder state (specifically queues and dynamic-table index trackers) to the receipt of remote Section Acknowledgment or Stream Cancellation instructions rather than the actual termination of the HTTP/3 stream.\nThe QpackEncoder maintains tracking information for every encoded field section that references the QPACK dynamic table. This tracking data is keyed by the peer-controlled QUIC stream ID. Because the state is not released upon the completion of the HTTP/3 stream, the server retains metadata and buffers indefinitely for every stream initiated by the client if the client refrains from sending the necessary acknowledgment signals.\nThe attack flow begins when an unauthenticated attacker establishes a QUIC connection and initializes an HTTP/3 session. The attacker advertises a non-zero QPACK dynamic-table capacity, triggering the server to utilize dynamic indexing for response headers. The attacker then acknowledges table insertions to encourage the server to cache these entries.\nOnce the server is primed, the attacker issues sequential requests over the connection while explicitly omitting the mandatory Section Acknowledgments required by the QPACK protocol. Because the server lacks an internal limit on the number of tracked streams, field sections, or the total size of retained bytes, the heap usage grows monotonically. By cycling through many streams without acknowledging them, the attacker forces the QpackEncoder to allocate increasingly large amounts of memory to track stale stream states.\nThis behavior bypasses existing concurrent-stream limits because the resource exhaustion occurs in the encoder state management, which is decoupled from the active stream concurrency window. The accumulation continues until the Java Virtual Machine (JVM) experiences an OutOfMemoryError, effectively crashing the server. Since the state is stored in the heap and is strictly tied to the client-controlled QUIC stream ID, a single connection can be sufficient to trigger this memory exhaustion, provided the attacker maintains the connection long enough to exceed available heap resources."
}