CVE-2026-1605
7.5Eclipse Foundation · Eclipse Jetty
Eclipse Jetty is vulnerable to a resource leak in the GzipHandler class, which can lead to uncontrolled memory consumption when processing specific uncompressed HTTP responses.
Executive summary
An unauthenticated resource consumption vulnerability in Eclipse Jetty allows remote attackers to cause a denial of service via memory exhaustion.
Vulnerability
The vulnerability exists in the GzipHandler class, where the JDK Inflater is allocated for decompressing requests but fails to release resources if the corresponding response is not compressed. This is an unauthenticated vulnerability that allows any remote user to trigger a memory leak.
Business impact
The primary risk associated with this vulnerability is a denial of service, which can cause significant operational disruption by exhausting server resources. Given the CVSS score of 7.5, this high severity flaw warrants immediate attention to maintain system availability and prevent potential service outages caused by malicious or accidental resource depletion.
Remediation
Immediate Action: Update the Eclipse Jetty server to version 12.0.32 or 12.1.6 to implement the patch that ensures proper release of the Inflater resource.
Proactive Monitoring: Monitor server memory utilization and log files for abnormal spikes in resource consumption or frequent errors related to the GzipHandler component.
Compensating Controls: Deploy a Web Application Firewall (WAF) to filter or block malformed HTTP requests that utilize the gzip content-encoding header if patching is not immediately feasible.
Exploitation status
Public Exploit Available: No (exploit_available: false)
Analyst recommendation
This vulnerability presents a clear risk to the availability of applications utilizing the affected Eclipse Jetty versions. Security teams should prioritize patching as the primary remediation strategy to ensure the integrity of the memory management lifecycle and prevent potential denial of service attacks.
More Eclipse Foundation CVEs
Sources
Originally found and disclosed by Gleb Sizov (@glebashnik), Bjørn Christian Seime (@bjorncs), per the CVE Program record.