CVE-2026-19204: Jetty WebSocket DoS Vulnerability

CVE-2026-19204 Overview

CVE-2026-19204 is a denial-of-service vulnerability in the Eclipse Jetty WebSocket implementation. A remote client can send a WebSocket frame with an unknown opcode and a very large declared payload length. Jetty attempts to allocate memory for that payload before validating the opcode. This bypasses the normal maximum frame size handling when auto-fragmentation is enabled and can exhaust the Java Virtual Machine (JVM) heap. The flaw maps to CWE-770: Allocation of Resources Without Limits or Throttling. No authentication or user interaction is required to trigger the condition.

Critical Impact
An unauthenticated remote attacker can exhaust JVM heap memory on a Jetty server by sending a single crafted WebSocket frame, resulting in service disruption.

Affected Products

Eclipse Jetty (WebSocket module with auto-fragmentation enabled)
Applications embedding vulnerable Jetty WebSocket versions
Java services exposing WebSocket endpoints backed by Jetty

Discovery Timeline

2026-09-07 - CVE-2026-19204 published to the National Vulnerability Database (NVD)
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-19204

Vulnerability Analysis

The Jetty WebSocket parser reads the frame header, extracts the opcode, and reads the declared payload length. When auto-fragmentation is enabled, the parser typically enforces a maximum frame size and fragments oversized payloads. Frames carrying an unknown opcode take a different code path. The parser allocates a buffer sized to the attacker-declared payload length before it validates the opcode. A client sending a frame with a fabricated opcode and a multi-gigabyte length field triggers a large allocation. The allocation attempt can exhaust the JVM heap and produce an OutOfMemoryError, halting request processing.

Root Cause

The root cause is missing input validation ordering. The opcode check must occur before any payload buffer is allocated. Because the unknown opcode branch skips the maximum frame size enforcement, the declared payload length is trusted without bound. This is a classic uncontrolled resource consumption defect tracked under CWE-770.

Attack Vector

Exploitation requires only network access to a Jetty WebSocket endpoint. An attacker completes the WebSocket handshake, then transmits a single frame containing a reserved or undefined opcode along with a very large Payload len value (using the 64-bit extended length field). The server attempts to allocate a buffer matching that length before rejecting the frame. Repeated frames or a single sufficiently large frame can consume all available heap. See the GitHub Security Advisory GHSA-85fq-fc5f-7j7g for vendor details.

No verified exploit code is published. The vulnerability mechanism is described in prose only; refer to the vendor advisory for technical specifics.

Detection Methods for CVE-2026-19204

Indicators of Compromise

OutOfMemoryError: Java heap space entries in Jetty server logs tied to WebSocket processing threads
Sudden JVM garbage collection pressure or process termination shortly after WebSocket connection establishment
WebSocket frames received with opcodes outside the defined set (0x0, 0x1, 0x2, 0x8, 0x9, 0xA) and payload lengths in the multi-megabyte or gigabyte range

Detection Strategies

Instrument the WebSocket layer to log rejected frames including opcode and declared payload length values
Alert on JVM heap utilization crossing configured thresholds on hosts running Jetty
Correlate OutOfMemoryError stack traces referencing org.eclipse.jetty.websocket packages with source IP addresses of recent WebSocket clients

Monitoring Recommendations

Track WebSocket frame opcode distribution at the reverse proxy or WAF layer
Monitor per-connection byte counts and declared payload lengths for anomalies
Forward JVM metrics and Jetty access logs to a centralized analytics platform for correlation

How to Mitigate CVE-2026-19204

Immediate Actions Required

Apply the patched Jetty release referenced in the GHSA-85fq-fc5f-7j7g advisory as soon as it is available
Inventory all Java applications embedding Jetty and identify those exposing WebSocket endpoints
Restrict inbound access to WebSocket endpoints to trusted networks where feasible until patching completes

Patch Information

Eclipse Jetty maintainers published fix details in GitHub Security Advisory GHSA-85fq-fc5f-7j7g. The fix validates the WebSocket opcode before allocating any payload buffer and enforces the maximum frame size on frames with unknown opcodes.

Workarounds

Disable WebSocket auto-fragmentation on affected servers if the deployment can tolerate the change
Deploy a reverse proxy or WAF rule that rejects WebSocket frames declaring payload lengths above a defined maximum
Lower the JVM heap ceiling and configure process supervision so a single failing instance is restarted rather than degrading the host

bash

# Example reverse proxy guardrail: cap WebSocket frame size upstream of Jetty
# NGINX example — enforce a client body/frame ceiling on the WebSocket path
location /ws/ {
    proxy_pass http://jetty_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    client_max_body_size 1m;
    proxy_read_timeout 60s;
}