CVE-2026-12611 in Jetty
Summary
by MITRE • 09/08/2026
A client may issue HTTP/2 requests to a Jetty server that result in blocking writes that are never unblocked, eventually causing all threads to be blocked and the whole server to become unresponsive.
This is caused by a race condition in the server when handling RST_STREAM frames and GOAWAY frames sent by the client.
The race condition "resets" the HTTP2Flusher.terminated, previously set to a non-null value, to the null value, allowing entries to be enqueued in the flusher that however will never be processed. These unprocessed entries are the ones that would unblock the write-blocked threads.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability described represents a critical denial of service condition within Jetty servers operating over HTTP/2 protocols. This flaw allows an attacker or misbehaving client to induce a state where all server threads become blocked, rendering the entire application unresponsive and unavailable for legitimate traffic. The root cause lies in a race condition involving the handling of specific control frames sent by the client, specifically RST_STREAM and GOAWAY messages. These frames are standard mechanisms in HTTP/2 used to reset streams or gracefully shut down connections, but their interaction with Jetty's internal flushing logic creates a fatal flaw that disrupts normal server operations.
The technical mechanism behind this vulnerability centers on the state management of the HTTP2Flusher component within the Jetty implementation. Under normal circumstances, when write operations are blocked due to backpressure or other constraints, the system relies on specific entries in the flusher queue to eventually unblock these threads and resume data transmission. However, a race condition occurs during the processing of RST_STREAM or GOAWAY frames from the client side. This race condition incorrectly resets the HTTP2Flusher.terminated flag from a non-null value back to null. In Jetty's architecture, this terminated state is crucial for signaling that no further entries should be processed and that existing blocked threads will eventually wake up through other mechanisms. By resetting this flag to null, the server inadvertently allows new write operations or queue entries to be enqueued into the flusher.
The consequence of these incorrectly enqueued entries is severe because they are never actually processed by the flushing mechanism due to the altered state logic. These unprocessed entries represent the very signals that would normally trigger the unblocking of threads waiting on I/O operations. As a result, any thread blocked while attempting to write data remains in a permanent wait state. Since HTTP/2 servers typically rely on a fixed pool of threads to handle concurrent connections and requests, the accumulation of these permanently blocked threads leads to resource exhaustion within the server's thread pool. Once all available worker threads are stuck waiting for unresolvable I/O completions, the server loses its capacity to accept new connections or process existing ones effectively.
From an operational impact perspective, this vulnerability results in a complete service outage for any Jetty instance susceptible to it. An attacker does not need elevated privileges or complex exploitation techniques; they merely need to send specific HTTP/2 control frames that trigger the race condition. This makes the vulnerability particularly dangerous as it can be exploited remotely with minimal effort. The impact aligns closely with CWE-367, which describes Time-of-check to time-of-use (TOCTOU) race conditions, where the state of a system is checked and then used in an unsafe manner due to changes occurring between the check and use. Furthermore, this behavior can be categorized under MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically through resource exhaustion via application layer flooding or logic exploitation rather than simple volume-based attacks.
Mitigation strategies must focus on preventing the race condition from affecting critical state variables like the flusher termination flag. Developers should implement robust synchronization mechanisms to ensure that updates to shared states such as HTTP2Flusher.terminated are atomic and protected against concurrent modifications during frame processing. Additionally, input validation for RST_STREAM and GOAWAY frames can help identify malformed or maliciously timed requests before they reach the critical code paths involved in thread management. Upgrading to patched versions of Jetty that address this specific race condition is the primary remediation step. Until patches are applied, deploying a web application firewall capable of detecting anomalous HTTP/2 frame patterns may provide some level of protection by blocking suspicious sequences of control frames before they can trigger the vulnerability.