CVE-2026-1605
Received Received - Intake
Resource Leak in Eclipse Jetty GzipHandler on Compressed Requests

Publication date: 2026-03-05

Last updated on: 2026-03-06

Assigner: Eclipse Foundation

Description
In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed. This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-05
Last Modified
2026-03-06
Generated
2026-05-07
AI Q&A
2026-03-05
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
eclipse jetty From 12.0.0 (inc) to 12.0.32 (exc)
eclipse jetty From 12.1.0 (inc) to 12.1.6 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
CWE-400 The product does not properly control the allocation and maintenance of a limited resource.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': "CVE-2026-1605 is a high-severity memory leak vulnerability in the Eclipse Jetty server's GzipHandler component affecting versions 12.0.0 through 12.0.31 and 12.1.0 through 12.1.5."}, {'type': 'paragraph', 'content': 'The issue occurs when the server processes an HTTP request that is compressed with "Content-Encoding: gzip" but the corresponding response is not compressed. In this scenario, the GzipRequest inflator object is created to decompress the request but is never released because the release mechanism is only triggered when the response is also compressed.'}, {'type': 'paragraph', 'content': 'Technically, the method gzipRequest.destroy() that releases the inflator is only called if both request inflation and response deflation are needed. If the response is not compressed, this method is never invoked, causing thousands of Inflater objects to accumulate in memory.'}, {'type': 'paragraph', 'content': 'This leads to uncontrolled resource consumption, specifically memory leaks in both Java heap and native memory, which can cause out-of-memory errors and JVM crashes.'}] [1]


How can this vulnerability impact me? :

[{'type': 'paragraph', 'content': "This vulnerability can be exploited to cause denial-of-service (DoS) attacks by exhausting the JVM's memory resources."}, {'type': 'paragraph', 'content': 'Because the Inflater objects are not released properly, memory consumption grows uncontrollably, potentially leading to out-of-memory errors and crashes of the Jetty server.'}, {'type': 'paragraph', 'content': 'Such crashes can disrupt availability of services relying on the Jetty server, causing downtime and impacting users.'}] [1]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusually high memory usage or out-of-memory errors in the JVM running the Jetty server, especially when handling HTTP requests with the header "Content-Encoding: gzip" but without "Accept-Encoding: gzip" in the response.'}, {'type': 'paragraph', 'content': 'Since the issue involves accumulation of java.util.zip.Inflater objects leading to memory leaks, you can look for symptoms such as JVM crashes or excessive native memory consumption.'}, {'type': 'paragraph', 'content': 'To detect the vulnerability on your system, you can use JVM monitoring tools like jcmd, jmap, or jstat to observe memory usage and object counts.'}, {'type': 'list_item', 'content': 'Use jcmd to get a heap histogram: jcmd <pid> GC.heap_info'}, {'type': 'list_item', 'content': 'Use jmap to dump heap and analyze Inflater objects: jmap -histo <pid> | grep Inflater'}, {'type': 'list_item', 'content': 'Monitor JVM logs for OutOfMemoryError or native memory exhaustion.'}, {'type': 'list_item', 'content': 'Analyze network traffic to identify HTTP requests with "Content-Encoding: gzip" headers without corresponding "Accept-Encoding: gzip" in responses.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

The recommended immediate mitigation is to disable the GzipHandler in the affected Jetty server versions to prevent the memory leak from occurring.

Since no patches are currently available, disabling the GzipHandler will stop the creation of GzipRequest inflator objects that are not properly released.

Additionally, monitor your JVM memory usage and consider restarting the Jetty server if memory exhaustion symptoms appear.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart