CVE-2024-7708: Eclipse Jetty Information Disclosure Flaw

CVE-2024-7708 Overview

CVE-2024-7708 is a resource management vulnerability in Eclipse Jetty affecting how the server handles request bodies. When Jetty processes requests that include a body but the read operation returns zero bytes, the allocated buffer is not released. This condition arises most commonly during 100-Continue handshakes and any scenario where slow network conditions delay body delivery. Repeated triggering exhausts server memory and leads to denial of service. The flaw is tracked under CWE-400: Uncontrolled Resource Consumption and impacts the availability of Jetty-based web applications and services.

Critical Impact
Remote unauthenticated attackers can trigger persistent buffer leaks over the network, exhausting server memory and causing denial of service in Eclipse Jetty deployments.

Affected Products

Eclipse Jetty (see vendor advisory for version ranges)
Applications embedding Eclipse Jetty as an HTTP server
Services relying on Jetty for 100-Continue request handling

Discovery Timeline

2026-07-14 - CVE-2024-7708 published to the National Vulnerability Database
2026-07-14 - Last updated in NVD database

Technical Details for CVE-2024-7708

Vulnerability Analysis

The vulnerability resides in Jetty's HTTP request body processing pipeline. When a client sends a request that declares a body, Jetty allocates an internal buffer to receive the payload. If the read operation returns zero bytes because the client has not yet transmitted data, the code path fails to release the buffer back to the pool. Over many requests, the leaked buffers accumulate in the JVM heap. This resource exhaustion pattern degrades service performance and ultimately triggers OutOfMemoryError conditions that crash the server process.

The issue maps to CWE-400: Uncontrolled Resource Consumption and impacts availability without exposing confidential data or enabling integrity violations.

Root Cause

The root cause is missing buffer cleanup logic in the code path that handles zero-byte reads from the request body. Jetty allocates buffers eagerly when it detects a request body, but the release logic assumes at least one non-zero read will occur. Zero-byte reads bypass the cleanup routine, leaving orphaned buffers referenced by the request state until garbage collection reclaims them, which does not occur while requests remain in flight.

Attack Vector

An attacker sends HTTP requests to a Jetty server that advertise a body via Content-Length or Transfer-Encoding headers, then either delays sending the body or leverages the Expect: 100-Continue mechanism. Each request causes Jetty to allocate a buffer that is never released. By repeating this pattern from one or more clients, attackers deplete server memory without authentication or user interaction. The attack scales with the number of concurrent requests and requires no specialized tooling beyond a standard HTTP client capable of controlling body transmission timing.

See the Eclipse CVE Assignment Work Item for vendor-provided technical details.

Detection Methods for CVE-2024-7708

Indicators of Compromise

Sustained growth of JVM heap usage on Jetty servers without corresponding traffic increase
Elevated frequency of Expect: 100-Continue requests followed by delayed or absent body transmission
OutOfMemoryError entries in Jetty logs referencing buffer allocation paths
Increased latency and connection timeouts under otherwise normal request loads

Detection Strategies

Monitor JVM heap and direct buffer pool metrics via Java Management Extensions (JMX) for abnormal growth patterns
Correlate HTTP access logs to identify clients sending Content-Length headers without matching body payloads
Alert on repeated 100-Continue handshakes from single source addresses that do not complete request submission

Monitoring Recommendations

Instrument Jetty with metrics collectors that expose ByteBufferPool statistics and track allocation versus release counts
Configure application performance monitoring to flag JVM garbage collection cycles that fail to reclaim heap space
Aggregate web server telemetry into a centralized log platform to identify slow-body request patterns across the fleet

How to Mitigate CVE-2024-7708

Immediate Actions Required

Upgrade Eclipse Jetty to the patched release identified in the Eclipse CVE Assignment Work Item
Inventory all applications and appliances that embed Jetty and prioritize internet-facing instances for patching
Restart Jetty processes after patching to clear any previously leaked buffers from memory

Patch Information

Eclipse has tracked remediation through the Eclipse CVE Assignment Work Item. Administrators should consult the vendor advisory to identify the fixed version applicable to their deployment branch and apply the update following standard change management procedures.

Workarounds

Place a reverse proxy such as NGINX or HAProxy in front of Jetty to buffer request bodies and reject slow or malformed clients before they reach the origin
Configure aggressive request timeouts and connection limits in Jetty to bound the impact of stalled requests
Disable or restrict Expect: 100-Continue handling at the proxy layer where application requirements permit
Enforce per-client connection quotas and rate limits at the network edge to reduce leak amplification

bash

# Example Jetty timeout configuration to limit stalled request impact
# jetty.xml snippet
<Set name="idleTimeout">30000</Set>
<Set name="stopTimeout">5000</Set>
<Call name="addBean">
  <Arg>
    <New class="org.eclipse.jetty.server.LowResourceMonitor">
      <Set name="maxConnections">2000</Set>
      <Set name="maxMemory">0</Set>
      <Set name="lowResourcesIdleTimeout">1000</Set>
    </New>
  </Arg>
</Call>