CVE-2026-19204
HighCVSS 8.7Exploitation Probability (EPSS)
Low risk22th percentile - higher than 22% of all known CVEs
Summary
A client may send a WebSocket frame with an unknown opcode and a very large declared payload length, causing Jetty to attempt a large memory allocation and potentially exhaust the JVM heap. This occurs when auto-fragmentation is enabled, as unknown opcodes bypass the normal maximum frame size handling and payload allocation occurs before the opcode is validated.
Risk Assessment
A remote attacker can cause JVM heap exhaustion, leading to denial of service and unavailability of the application.
Recommendation
Update Jetty to a version that includes a fix for this vulnerability. If not possible, consider disabling auto-fragmentation or restricting WebSocket access.
Other vulnerabilities in Jetty
See all- CVE-2026-19203High
A client may issue specially crafted HTTP/1.1 chunked requests to a Jetty server that cause Jetty and an intermediary proxy to interpret different request boundaries, potentially resulting in HTTP request smuggling. This is caused by Jetty accepting a lone LF character as a terminator in parts of chunked request parsing. Depending on the Jetty version and configured HTTP compliance mode, this may occur in chunk extensions, chunk data termination, or trailer termination.
- CVE-2026-12611High
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.
- CVE-2017-9735High
Jetty through 9.4.x is prone to a timing channel in util/security/Password.java, which makes it easier for remote attackers to obtain access by observing elapsed times before rejection of incorrect passwords.
Original NVD description (English source)
A client may send a WebSocket frame with an unknown opcode and a very large declared payload length, causing Jetty to attempt a large memory allocation and potentially exhaust the JVM heap. This occurs when auto-fragmentation is enabled, as unknown opcodes bypass the normal maximum frame size handling and payload allocation occurs before the opcode is validated.