high · 7.5CVE-2024-7708Jul 22, 2026

CVE-2024-7708: Eclipse Jetty jetty-server Buffer Leak DoS via 100-Continue Requests

Rohit Hatagale
AI Security Researcher, SecureLayer7

Sending repeated HTTP requests with an Expect: 100-continue header causes Jetty to silently leak a read buffer per request, allowing any unauthenticated attacker to exhaust server memory and cause a…

Packageorg.eclipse.jetty:jetty-server
Ecosystemmaven
Affected>= 10.0.7, < 10.0.23
Fixed in10.0.23

The problem

In Eclipse Jetty 10.0.7 through 10.0.22 (and 11.0.0 through 11.0.22), the HTTP/1.1 connection handler inside HttpConnection allocates a RetainableByteBuffer when it begins reading a request body. If the network fill returns 0 bytes, the buffer is not released, and a reference leak accumulates silently.

The most reliable trigger is any request that carries a body but pauses before sending it, most notably POST or PUT requests using the Expect: 100-continue handshake. Because no authentication is required and the leak occurs at the connection layer, an attacker can drain heap memory at network speed.

Proof of concept

A working proof-of-concept for CVE-2024-7708 in org.eclipse.jetty:jetty-server, with the exact payload below.

http
# Loop this in a script or with a tool like wrk/ab to trigger heap exhaustion.
# Each request leaks one RetainableByteBuffer; Jetty never releases it when fill() returns 0.

POST /any-endpoint HTTP/1.1
Host: target.example.com
Content-Type: application/octet-stream
Content-Length: 1048576
Expect: 100-continue
Connection: close

# --> Send headers, wait for server to issue '100 Continue',
#     then immediately close/reset the connection WITHOUT sending the body.
# Repeat thousands of times concurrently until JVM throws OutOfMemoryError.

The root cause is in HttpConnection (jetty-server). When fill() returns 0 during a body read, the code path exited early without calling release() on the already-acquired RetainableByteBuffer. Every such partial read left a pooled buffer permanently pinned in memory (CWE-401 / CWE-400).

The 100-continue flow reliably hits this path because Jetty eagerly allocates the read buffer before the client has sent a single body byte. Slow or aborted clients on any body-bearing request produce the same leak, making the attack surface broader than 100-continue alone.

PR #12156 (commit 8259eab) fixed HttpConnection to always release the retained buffer when a zero-byte fill is detected, closing the reference leak entirely.

The fix

Upgrade to jetty-server 10.0.23 or 11.0.23. No configuration workaround exists. The fix is in PR #12156 / commit 8259eabbc70ae7fc2d525f1e95b43fbdfd2ad097, which ensures HttpConnection releases its RetainableByteBuffer on every zero-byte fill path.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research