CVE-2024-13009: **UNSUPPORTED WHEN ASSIGNED** GzipHandler causes part of request body to be seen as request body of a separate request
7.2
Basic Information
JavaTechnical Details
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.eclipse.jetty:jetty-server | maven | >= 9.4.0, <= 9.4.56 | 9.4.57.v20241219 |
Vulnerability Intelligence
Miggo AI
Miggo AIRoot Cause Analysis
The vulnerability (GHSA-q4rv-gq96-w7c5 / CVE-2024-13009) states that in Eclipse Jetty, GzipHandler can cause incorrect buffer release during GZIP inflation errors, leading to data corruption or sharing between requests. The provided commit e3fa9466633db6bf36e0eb0d17e3de166c788ede directly addresses this by modifying buffer management logic within org.eclipse.jetty.server.HttpInput.java.
The GzipHandler uses an interceptor (GzipInterceptor) which, in turn, interacts with HttpInput to read and decompress the request body. When a GZIP inflation error occurs within this interceptor, the error state propagates to HttpInput.
The patch modifies two key methods in HttpInput.java:
fail(Content, Throwable): The patch ensures that if the content being marked as failed is the current active buffer (_content), then_contentis set tonull. Previously, this nullification was missing, allowing a reference to the (potentially partially filled or corrupted) buffer from the failed GZIP operation to persist.addContent(Content): Similarly, when adding content in an error or EOF state (which could follow a GZIP error), the patch ensures that if the content being added is the current_content, it is nullified. This prevents the problematic buffer from being carried forward.
These HttpInput methods are identified as vulnerable because their pre-patch logic for managing the _content buffer was flawed under error conditions originating from interceptors like the one used by GzipHandler. This mismanagement of the buffer is the root cause of the described vulnerability, where parts of one request's body (after a GZIP error) could be mistakenly seen as part of a subsequent request due to the buffer not being properly cleared and reset.
While GzipHandler.handle(...) would be a primary function in the stack trace during exploitation as it orchestrates the GZIP processing, the actual code flaw (incorrect buffer handling) fixed by this specific patch resides in the identified HttpInput methods. These methods are crucial for processing the request input stream, and their incorrect behavior when handling GZIP errors led to the vulnerability.