CVE-2026-100660: 
Java vulnerability analysis and mitigation

CVE-2026-100660 is a denial-of-service vulnerability in Netty's HTTP/3 codec (io.netty:netty-codec-http3) caused by unbounded per-stream QPACK encoder state retention. It affects versions 4.2.0.Final through 4.2.17.Final and was disclosed on September 26, 2026, with the fix released in 4.2.18.Final. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Netty Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). QpackEncoder stores a Queue<Indices> object in a LongObjectHashMap (streamSectionTrackers) for every encoded field section that references the QPACK dynamic table, keyed by the peer-controlled QUIC stream ID. These entries are only removed when the remote decoder sends a Section Acknowledgment (sectionAcknowledgment()) or Stream Cancellation (streamCancellation()) instruction — not upon HTTP/3 stream completion. Because Netty imposes no limit on the number of tracked streams, field sections, or retained bytes, a malicious client can exploit this by acknowledging the initial dynamic-table insertion (via an Insert Count Increment instruction) to enable server-side header reuse, then withholding all subsequent Section Acknowledgments across sequentially opened and closed requests on a single QUIC connection, bypassing concurrent-stream limits entirely. A complete, runnable Java PoC (QpackRetentionPoC.java) is publicly available in the Netty security advisory (Netty Advisory).

Successful exploitation results in unbounded heap growth on the Netty server, leading to excessive garbage-collection pressure, OutOfMemoryError, or process-wide denial of service. The attack requires no authentication, no user interaction, no malformed frames, and no high per-request bandwidth — a single long-lived QUIC connection is sufficient. There is no confidentiality or integrity impact; the vulnerability is limited to availability of the affected server process (Netty Advisory, GitHub Advisory).

A proof-of-concept exploit (QpackRetentionPoC.java) is publicly available in the Netty security advisory, demonstrating that 25,000 sequentially completed streams without Section Acknowledgments leave 25,000 retained tracker objects (Netty Advisory). The attack is classified as automatable with no authentication or user interaction required. The EPSS score is 0.375% (29th percentile), and there is no evidence of in-the-wild exploitation or CISA KEV catalog inclusion as of the time of disclosure (GitHub Advisory).

1. Reconnaissance: Identify servers running Netty HTTP/3 codec versions 4.2.0.Final through 4.2.17.Final that are reachable over QUIC (typically UDP port 443).
2. Establish HTTP/3 connection with QPACK dynamic-table support: Send a QUIC connection establishment with a SETTINGS frame advertising a non-zero SETTINGS_QPACK_MAX_TABLE_CAPACITY, signaling willingness to use the QPACK dynamic table.
3. Trigger dynamic-table indexing: Send the first HTTP/3 request and receive a server response containing a repeatable, non-sensitive header (e.g., x-qpack-retain: constant-value) eligible for QPACK dynamic-table insertion. The server's QpackEncoder.encodeHeaders() creates an Indices object stored in streamSectionTrackers keyed by stream ID.
4. Acknowledge the dynamic-table insertion: Send a valid QPACK decoder-stream Insert Count Increment instruction (0x01) so the server believes the decoder received the dynamic entry and will reuse it for subsequent responses without blocking.
5. Omit Section Acknowledgments for all subsequent streams: Open new sequential requests (e.g., stream IDs 0, 4, 8, ... for client-initiated bidirectional streams), receive responses with the dynamically indexed header, but deliberately never send the mandatory QPACK Section Acknowledgment. Each stream adds a new Queue<Indices> entry to streamSectionTrackers that is never removed.
6. Exhaust server heap: Repeat step 5 across tens of thousands of sequentially completed streams. Each completed stream accumulates a retained tracker object, causing linear heap growth until the server throws OutOfMemoryError or becomes unresponsive due to garbage-collection pressure (Netty Advisory).

• Network: Single long-lived QUIC connection (UDP, typically port 443) from one client IP issuing a very large number of sequential HTTP/3 requests without corresponding QPACK Section Acknowledgment frames on the decoder stream; absence of QPACK decoder-stream traffic (stream type 0x03) after the initial Insert Count Increment.
• Process/JVM: Continuously increasing JVM heap usage on the Netty server process without corresponding increase in active connections or request throughput; frequent full garbage-collection cycles with little heap reclamation; eventual java.lang.OutOfMemoryError in JVM logs.
• Logs: Server-side application logs showing a high volume of requests from a single QUIC connection/client IP; JVM GC logs indicating sustained heap pressure correlated with HTTP/3 traffic; potential OutOfMemoryError stack traces referencing io.netty.handler.codec.http3.QpackEncoder or LongObjectHashMap.
• Metrics: Anomalous growth in JVM heap metrics (e.g., via JMX or Prometheus JVM exporter) without a corresponding increase in active HTTP/3 streams; streamSectionTrackers map size growing unboundedly (observable via JVM heap dump analysis) (Netty Advisory).

Upgrade io.netty:netty-codec-http3 to version 4.2.18.Final or later, which fixes the unbounded tracker retention (Netty Advisory, GitHub Advisory). If immediate upgrading is not feasible, consider restricting network access to HTTP/3 (QUIC/UDP) endpoints to trusted clients, implementing rate limiting or connection throttling on QUIC connections, or disabling QPACK dynamic-table usage by setting SETTINGS_QPACK_MAX_TABLE_CAPACITY to zero if the application permits it (Red Hat Bugzilla).

The vulnerability was reported by researcher hussst and published by Netty maintainer chrisvest on September 10, 2026 via the Netty GitHub security advisory (Netty Advisory). Red Hat tracked the issue via Bugzilla and assigned it high severity (Red Hat Bugzilla). No significant broader community controversy or social media discussion has been identified beyond standard CVE tracking and vendor acknowledgment.