CVE-2025-1948:
Eclipse Jetty HTTP/2 client can force the server to allocate a humongous byte buffer that may lead to OoM and subsequently the JVM to exit
7.5
Basic Information
JavaTechnical Details
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.eclipse.jetty.http2:jetty-http2-common | maven | >= 12.0.0, <= 12.0.16 | 12.0.17 |
Vulnerability Intelligence
Miggo AI
Miggo AIRoot Cause Analysis
The vulnerability occurs because the Jetty HTTP/2 server does not validate the SETTINGS_MAX_HEADER_LIST_SIZE parameter received from a client. The server then attempts to use this value to configure its HPACK encoder, which is responsible for preparing HTTP response headers. If the client provides an excessively large value, the server tries to allocate a correspondingly large ByteBuffer for encoding, leading to an OutOfMemoryError.
The primary fix is in org.eclipse.jetty.http2.HTTP2Session.configure(). This method receives the settings from the client. The patch specifically changes how the SETTINGS_MAX_HEADER_LIST_SIZE is applied to the HpackEncoder (used for encoding responses). Previously, it directly set the encoder's max size to the client-provided value. The fix introduces Math.min() to cap this value against the encoder's own configured maximum (or a default), preventing it from becoming excessively large.
The change in org.eclipse.jetty.http2.hpack.HpackEncoder.setMaxHeaderListSize() is a secondary hardening measure, ensuring that the max size is always positive and defaults to a reasonable value if a non-positive value is passed, but the main vulnerability exploitation path is through HTTP2Session.configure() not capping the value from the client before it reaches the encoder's configuration.
The commit 8414f79a9c476ecb78998c8ce88f0c5ae548f7e6 directly addresses issue #12690 and modifies HTTP2Session.java to cap the MAX_HEADER_LIST_SIZE for the encoder, which is the core of the vulnerability.