CVE-2026-1605: Eclipse Jetty GzipHandler DOS Vulnerability

CVE-2026-1605 Overview

A resource exhaustion vulnerability exists in Eclipse Jetty's GzipHandler class that can lead to denial of service conditions. The vulnerability occurs when processing compressed HTTP requests with Content-Encoding: gzip where the corresponding response is not compressed. This creates a memory leak scenario where JDK Inflater objects are allocated but never released, potentially exhausting server resources.

Critical Impact

Attackers can exploit this vulnerability to cause denial of service by sending specially crafted compressed HTTP requests, leading to memory exhaustion on affected Jetty servers.

Affected Products

• Eclipse Jetty versions 12.0.0 through 12.0.31
• Eclipse Jetty versions 12.1.0 through 12.0.5

Discovery Timeline

• 2026-03-05 - CVE-2026-1605 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-1605

Vulnerability Analysis

This vulnerability (CWE-400: Uncontrolled Resource Consumption) stems from improper resource management in the GzipHandler component of Eclipse Jetty. When the server receives an HTTP request with compressed content (indicated by the Content-Encoding: gzip header), the handler allocates a JDK Inflater object to decompress the incoming request body.

The critical flaw lies in the resource release mechanism. The Inflater object's cleanup is tied to the response compression lifecycle rather than the request decompression lifecycle. When the server generates an uncompressed response, the release mechanism never triggers, causing the allocated Inflater to remain in memory indefinitely.

Root Cause

The root cause is a design flaw in the resource lifecycle management of the GzipHandler class. The JDK Inflater allocation for request decompression is incorrectly coupled with the response compression mechanism. This means:

1. An Inflater is allocated when a gzip-compressed request is received
2. The release of this Inflater is tied to the completion of response compression
3. If no response compression occurs, the Inflater is never released
4. Repeated requests lead to accumulated Inflater objects consuming memory

This architectural oversight creates a resource leak that can be exploited to exhaust server memory resources.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending multiple HTTP requests with gzip-compressed bodies to endpoints that return uncompressed responses. Each request causes an Inflater object to leak, and sustained attack traffic can gradually exhaust the server's available memory, ultimately causing service degradation or complete denial of service.

The vulnerability is particularly dangerous because:

• No special privileges are required to send HTTP requests
• The attack can be automated and scaled easily
• Normal logging may not immediately reveal the root cause of memory exhaustion

For detailed technical information, see the GitHub Security Advisory.

Detection Methods for CVE-2026-1605

Indicators of Compromise

• Gradual memory consumption increase on Jetty servers without corresponding increase in legitimate traffic
• High number of HTTP requests with Content-Encoding: gzip headers from single or distributed sources
• Heap dump analysis showing accumulated java.util.zip.Inflater objects
• Application performance degradation followed by OutOfMemoryError exceptions

Detection Strategies

• Monitor JVM heap memory utilization trends for Jetty-based applications
• Implement alerting on unusual growth patterns in memory consumption
• Analyze HTTP access logs for anomalous patterns of gzip-encoded requests
• Use application performance monitoring (APM) tools to track Inflater object allocation and lifecycle

Monitoring Recommendations

• Configure JVM garbage collection logging to identify memory pressure events
• Set up alerts for heap utilization exceeding baseline thresholds (e.g., 80% of max heap)
• Monitor HTTP request patterns for high volumes of compressed requests to endpoints returning uncompressed responses
• Implement rate limiting on endpoints as a defensive measure against sustained exploitation attempts

How to Mitigate CVE-2026-1605

Immediate Actions Required

• Identify all Jetty deployments running affected versions (12.0.0-12.0.31 and 12.1.0-12.0.5)
• Plan and execute upgrades to patched Jetty versions as soon as available
• Implement request rate limiting as a temporary mitigation measure
• Monitor server memory utilization closely until patches are applied

Patch Information

Eclipse Jetty has acknowledged this vulnerability. Administrators should consult the GitHub Security Advisory for official patch information and updated version releases. Upgrade to the latest patched version of Jetty as soon as it becomes available.

Workarounds

• Implement request rate limiting at the load balancer or WAF level to reduce the impact of potential exploitation
• Consider disabling gzip request decompression at the Jetty level if application requirements permit
• Deploy additional memory monitoring and automatic service restart mechanisms as a temporary measure
• Use reverse proxy configurations to handle gzip decompression before requests reach Jetty

# Example: Configure rate limiting at nginx reverse proxy level
# Add to nginx server block configuration
limit_req_zone $binary_remote_addr zone=jetty_limit:10m rate=10r/s;

location / {
    limit_req zone=jetty_limit burst=20 nodelay;
    proxy_pass http://jetty_backend;
}