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:

An Inflater is allocated when a gzip-compressed request is received
The release of this Inflater is tied to the completion of response compression
If no response compression occurs, the Inflater is never released
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

bash

# 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;
}