Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSummary
CVE-2026-1605 is a high-severity Uncontrolled Resource Consumption (CWE-400) vulnerability in Eclipse Jetty. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique OS Exhaustion Flood (T1499.001); ranked at the 47th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SC-5 (Denial-of-service Protection) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-1605 is a resource leak vulnerability in the GzipHandler class of Eclipse Jetty, affecting versions 12.0.0 through 12.0.31 and 12.1.0 through 12.0.5. The issue arises when processing a compressed HTTP request with Content-Encoding: gzip, where the JDK Inflater is allocated to decompress the request but not released. This occurs because the release mechanism is tied to generating a compressed response, which does not trigger if the response is uncompressed, leading to a memory leak. The vulnerability is rated 7.5 on the CVSS v3.1 scale (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and is associated with CWE-400 (Uncontrolled Resource Consumption) and CWE-401 (Memory Leak).
Unauthenticated remote attackers can exploit this vulnerability by sending HTTP requests with gzip-compressed content where the server responds without compression. Repeated exploitation causes progressive memory consumption as Inflater instances accumulate without release, potentially leading to denial of service through resource exhaustion.
For mitigation details, refer to the Jetty security advisory at https://github.com/jetty/jetty.project/security/advisories/GHSA-xxh7-fcf3-rj7f.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-9815
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (static analysis, fuzzing, or runtime leak detection) directly finds missing deallocation.
SC-5 directly limits the effects of resource-exhaustion events that constitute uncontrolled consumption.
SC-6 enforces explicit allocation limits on resources, structurally preventing the weakness from occurring.
Requiring documented development standards and tools can mandate memory-management disciplines that avoid leaks at introduction.
Engineering principles applied during development can require explicit resource-release patterns that stop memory leaks from being coded.
Process isolation confines resource consumption to separate domains, reducing blast radius without stopping the root flaw.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Lifecycle management explicitly requires handling resources through end-of-life including release.
Explicitly requires monitoring and maintaining resource capacity, directly addressing uncontrolled consumption to preserve availability.
Secure SDLC practices directly enforce proper memory allocation/deallocation via coding standards, reviews, and tooling.
Continuous monitoring of computing resources can detect resource exhaustion but does not itself enforce allocation limits.
Resilience mechanisms such as avoiding single points of failure indirectly reduce impact of resource exhaustion.
Hardened configuration baselines can include resource quotas and limits that constrain consumption.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Explicit information-deletion requirements directly address timely release of resources after use.
Resource-utilization monitoring and alerting on bottlenecks or overloads limits the impact of denial-of-service or resource-exhaustion attacks.
Security testing in development can detect unreleased memory, providing partial coverage of the weakness.
By continuously monitoring utilization, stress-testing peak loads, and maintaining documented plans to scale or throttle resources, the control directly limits an attacker’s ability to drive a system into uncontrolled resource exhaustion.
Pre-agreed severity-based prioritization and resource allocation during incident triage reduce the likelihood that an attacker-induced resource exhaustion will overwhelm the organization before corrective action is taken.
Business-continuity plans that include resource-management controls reduce the likelihood that an attacker can trigger uncontrolled resource consumption by forcing the system into a degraded or fallback state.