Cloudanix VulnDB

CVE-2026-1605

High · 7.5

CVSS

7.5

EPSS

0.7%

Published

Mar 5, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A server component can slowly lose memory when handling certain compressed web requests, eventually causing the service to slow down or stop responding.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Web Framework
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Unreleased JDK Inflater objects allocated for decompressing gzip-encoded HTTP requests leak when the corresponding response is not compressed, because GzipHandler ties release to response compression.

Why it matters to the business

Repeated requests can exhaust server memory leading to application slowdowns or crashes and loss of service availability for users and dependent systems.

How an attack unfolds

An attacker repeatedly sends HTTP requests carrying Content-Encoding: gzip where the server generates an uncompressed response; each request allocates an Inflater that is never released, gradually consuming heap until the process becomes unresponsive or crashes.

How to fix it

Upgrade Eclipse Jetty to a version containing the fix for the GzipHandler release logic once released; until then disable GzipHandler for request decompression or enforce that all responses to gzip requests are also compressed.

How to confirm the fix worked

Confirm Jetty version is updated, review heap dumps or GC logs for accumulating Inflater objects under gzip request load, and test that memory usage remains stable after applying the change.

Typical attack path

  1. Identify Jetty endpoints accepting gzip-encoded requests
  2. Craft and send requests with Content-Encoding: gzip that elicit uncompressed responses
  3. Repeat the requests at volume to accelerate memory consumption
  4. Monitor for service degradation or out-of-memory conditions

How to detect it

Monitor JVM heap usage and GC activity for steady growth correlated with gzip request volume; inspect access logs for repeated Content-Encoding: gzip entries paired with uncompressed responses; review thread or object histograms for unreleased Inflater instances.

What your security team should do

  • Prioritize upgrade of all Jetty 12.x instances as soon as a patched release is available
  • Temporarily disable request gzip decompression or enforce symmetric compression on responses
  • Add memory and request-pattern monitoring to detect anomalous consumption
  • Track EPSS and exploit maturity updates for changes in risk posture

The record

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.

Affected packages

Ecosystem Package Introduced Fixed
Maven org.eclipse.jetty:jetty-server 12.0.0 12.0.32
Maven org.eclipse.jetty:jetty-server 12.1.0 12.1.6
Chainguard apache-hop 0 2.17.0-r3
Chainguard apache-hop-fips 0 2.17.0-r3
Chainguard apache-jena-fuseki 0 6.0.0-r3
Chainguard confluent-kafka 0 8.3.0.375-r0
Chainguard confluent-kafka-jre-bcfips 0 8.3.0.411-r0
Chainguard dependency-track 0 4.14.0-r0
Chainguard dependency-track-apiserver 0 4.14.0-r0
Chainguard dependency-track-bundled 0 4.14.0-r0
Chainguard druid 0 36.0.0-r4
Chainguard jenkins-2.541 0 2.541.2-r2
Chainguard jenkins-2.541-openjdk-17 0 2.541.2-r2
Chainguard jenkins-2.541-openjdk-21 0 2.541.2-r2
Chainguard kafka-4.0 0 4.0.2-r1
Chainguard kafka-4.1 0 4.1.2-r1
Chainguard kafka-fips-4.1 0 4.1.2-r1
Chainguard neo4j-5.26 0 5.26.21-r3
Chainguard solr 0 10.0.0-r1
Chainguard strimzi-kafka-operator-cluster-operator 0 0.50.1-r4
Chainguard strimzi-kafka-operator-kafka-agent 0 0.50.1-r4
Chainguard strimzi-kafka-operator-kafka-init 0 0.50.1-r4
Chainguard strimzi-kafka-operator-topic-operator 0 0.50.1-r4
Chainguard strimzi-kafka-operator-tracing-agent 0 0.50.1-r4
Chainguard strimzi-kafka-operator-user-operator 0 0.50.1-r4
Chainguard trino 0 479-r7
Wolfi confluent-kafka 0 8.3.0.375-r0
Wolfi dependency-track 0 4.14.0-r0
Wolfi dependency-track-bundled 0 4.14.0-r0
Wolfi druid 0 36.0.0-r4
Wolfi kafka-4.0 0 4.0.2-r1
Wolfi kafka-4.1 0 4.1.2-r1
Wolfi neo4j-5.26 0 5.26.21-r3
Wolfi solr 0 10.0.0-r1
Wolfi strimzi-kafka-operator-cluster-operator 0 0.50.1-r4
Wolfi strimzi-kafka-operator-kafka-agent 0 0.50.1-r4
Wolfi strimzi-kafka-operator-kafka-init 0 0.50.1-r4
Wolfi strimzi-kafka-operator-topic-operator 0 0.50.1-r4
Wolfi strimzi-kafka-operator-tracing-agent 0 0.50.1-r4
Wolfi strimzi-kafka-operator-user-operator 0 0.50.1-r4
Wolfi trino 0 479-r7

Related vulnerabilities