Dos

CVE-2025-1948: Jetty's Big Buffer Blowout - How an HTTP/2 Setting Can Crash Your JVM

Robert Morgan

Robert Morgan

— 8 min read

Well, hello there, fellow cybernauts and code connoisseurs! Today, we're diving into a fascinating vulnerability that reminds us even the most modern protocols can have their "oops" moments. Grab your favorite beverage, because we're about to dissect CVE-2025-1948, a sneaky little bug in Eclipse Jetty that could turn your robust server into a sputtering, out-of-memory mess.

TL;DR / Executive Summary

CVE-2025-1948 affects Eclipse Jetty versions 12.0.0 through 12.0.16. A vulnerability in the HTTP/2 protocol implementation allows a remote attacker to trick the server into allocating an enormous byte buffer. This happens because Jetty doesn't properly validate the SETTINGS_MAX_HEADER_LIST_SIZE parameter sent by an HTTP/2 client. The consequence? Your server can run out of memory (OutOfMemoryError), leading to a Denial of Service (DoS) as the JVM might crash or become unresponsive. The severity is high due to the ease of exploitation and direct impact on service availability. The fix is available in Jetty version 12.0.17. Upgrade immediately if you're affected!

Introduction: The Promise and Peril of HTTP/2

HTTP/2! The protocol that promised us faster web browsing, multiplexing, server push, and header compression. It's like upgrading from a bicycle to a sports car for web traffic. But as with any complex machinery, sometimes a tiny, overlooked part can cause the whole engine to seize. That's precisely the case with CVE-2025-1948.

This vulnerability matters because Jetty is a widely used web server and servlet container. If you're running a Java application on Jetty, especially one leveraging HTTP/2 (which is increasingly common for performance), you could be at risk. Imagine your critical services grinding to a halt because a malicious actor sent a few cleverly crafted packets. Not a good look, right? Let's explore how this seemingly innocuous setting can wreak havoc.

Technical Deep Dive: When "Max" Means "Too Much"

Alright, let's get our hands dirty and look under the hood.

Vulnerability Details: The SETTINGS_MAX_HEADER_LIST_SIZE Trap

HTTP/2 communication begins with a connection preface, followed by an exchange of SETTINGS frames. These frames allow the client and server to agree on communication parameters. One such parameter is SETTINGS_MAX_HEADER_LIST_SIZE (identifier 0x6). This setting informs the peer about the maximum size, in octets, of the header list that it is prepared to accept. The idea is to prevent a peer from sending an overwhelmingly large set of headers.

The vulnerability in Jetty (versions 12.0.0 to 12.0.16) lies in how the server processes the SETTINGS_MAX_HEADER_LIST_SIZE value sent by the client. According to the GitHub advisory, "The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses."

So, a malicious client can say, "Hey Jetty, I'm cool with you sending me response headers up to, say, 2 Gigabytes!" And vulnerable Jetty versions would naively respond, "Okay, let me prepare a buffer of 2GB for your potential response headers!"

Root Cause Analysis: The Unchecked Request

The root cause is a classic case of missing input validation for resource allocation. Think of it like ordering a custom-sized box. You tell the box maker, "I need a box that's 100 miles long." A sensible box maker would laugh and say, "Sorry, pal, my factory isn't that big, and you probably don't need that anyway. How about a reasonably sized box?"

Vulnerable Jetty, in this scenario, is the overzealous box maker who actually tries to construct the 100-mile-long box. It attempts to allocate a java.nio.ByteBuffer with the capacity specified by the client's SETTINGS_MAX_HEADER_LIST_SIZE. If this value is astronomically large (e.g., Integer.MAX_VALUE or close to it), the JVM will try to allocate gigabytes of memory.

This allocation attempt will likely fail, throwing an OutOfMemoryError (OOM). Depending on the JVM's configuration and the severity of the OOM, the entire JVM process might terminate, leading to a complete service outage. Even if it doesn't crash immediately, repeated OOMs can severely degrade performance and stability.

Attack Vectors

The attack vector is straightforward:

  1. A malicious HTTP/2 client connects to a vulnerable Jetty server.
  2. During the initial HTTP/2 handshake, the client sends a SETTINGS frame.
  3. In this SETTINGS frame, the client specifies an extremely large value for SETTINGS_MAX_HEADER_LIST_SIZE.
  4. The Jetty server receives this setting and, without proper validation, attempts to allocate a ByteBuffer of that massive size for handling response headers.
  5. The allocation fails, leading to an OOM and potential server crash or unresponsiveness.

This can be triggered by any remote attacker capable of establishing an HTTP/2 connection to the server.

Business Impact

The business impact can be significant:

  • Denial of Service (DoS): The most direct impact. Your services become unavailable.
  • Reputational Damage: Frequent outages erode user trust.
  • Financial Loss: Downtime means lost revenue, SLA penalties, and recovery costs.
  • Resource Exhaustion: Even if the server doesn't crash, repeated OOMs can make it sluggish and unreliable for other users.

Proof of Concept (PoC): Making Jetty Sweat

While the original PoC was provided as a zip file by Bjørn Seime, we can outline how such an exploit would conceptually work. An attacker would use a custom HTTP/2 client library or tool (like nghttp2 with modifications, or a custom script using libraries like Python's h2) to send the malicious SETTINGS frame.

Conceptual PoC Steps:

  1. Establish TCP Connection: Connect to the target Jetty server on its HTTP/2 port.

  2. Send HTTP/2 Connection Preface: Send the standard client connection preface string: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n.

  3. Send Malicious SETTINGS Frame: Immediately after the preface, send an HTTP/2 SETTINGS frame. This frame would contain the SETTINGS_MAX_HEADER_LIST_SIZE parameter with a very large value.

    • Parameter ID for SETTINGS_MAX_HEADER_LIST_SIZE is 0x6.
    • Value: e.g., 0x7FFFFFFF (2,147,483,647 bytes, or ~2GB).

    A simplified representation of the malicious part of the communication:

    Client -> Server:
[SETTINGS Frame]
  Parameter: SETTINGS_MAX_HEADER_LIST_SIZE (ID: 0x6)
  Value: 2147483647

  4. Observe Server Behavior: The server, upon processing this SETTINGS frame, would attempt the huge memory allocation. This is where you'd expect to see OutOfMemoryError in the server logs, followed by instability or a crash.

Disclaimer: The following is a theoretical code snippet illustrating the client-side action. Do not use against systems you don't have permission to test.

# Theoretical Python PoC using a hypothetical HTTP/2 library
# (Actual implementation would use a library like 'h2')

# import http2_custom_library as h2
#
# target_host = "vulnerable-jetty-server.com"
# target_port = 443 # Or whatever port HTTP/2 is on
#
# conn = h2.connect(target_host, target_port, ssl=True)
#
# # Send connection preface (usually handled by library)
# # conn.send_connection_preface()
#
# # Craft malicious SETTINGS frame
# # SETTINGS_MAX_HEADER_LIST_SIZE ID is 0x6
# malicious_settings = {
#     0x6: 0x7FFFFFFF  # Set to a huge value (e.g., 2GB - 1)
# }
# conn.send_settings_frame(settings=malicious_settings)
#
# print(f"Sent malicious SETTINGS_MAX_HEADER_LIST_SIZE to {target_host}. Check server logs.")
#
# # Keep connection open or send a request to trigger processing
# # try:
# #     conn.send_request("GET", "/")
# # except Exception as e:
# #     print(f"Server might be down: {e}")
#
# conn.close()

This Python snippet is purely illustrative. A real exploit would require a library capable of fine-grained control over HTTP/2 frames.

Mitigation and Remediation: Patch Up and Stay Safe!

Fortunately, fixing this is straightforward.

Immediate Fixes:

  • Upgrade Jetty: The primary and most effective solution is to upgrade to Jetty version 12.0.17 or later. This version includes the patch that validates the SETTINGS_MAX_HEADER_LIST_SIZE value.

Long-Term Solutions:

  • Input Validation as a Principle: This vulnerability underscores the importance of validating all external inputs, especially those that dictate resource allocation.
  • Resource Limiting: Implement sensible default and maximum limits for various parameters at different layers of your application stack.
  • Web Application Firewall (WAF): While not a direct fix for this specific low-level protocol issue, a WAF might be configurable to drop HTTP/2 connections with anomalous SETTINGS parameters, though this is less common. The fix should be at the application level.

Verification Steps:

  1. Check Jetty Version: Ensure your deployment is running Jetty 12.0.17 or newer. You can typically find this in startup logs or by checking the MANIFEST.MF file within Jetty's JARs.
  2. Monitor Memory Usage: After patching, monitor your server's memory usage, especially under load and during initial HTTP/2 connection setups. Look for stable memory patterns and the absence of OOM errors.
  3. Controlled Test (If Possible): If you have a non-production environment, you could (with extreme caution and proper tooling) attempt to send a SETTINGS frame with a moderately large (but not system-crashing) SETTINGS_MAX_HEADER_LIST_SIZE to see if the patched server handles it gracefully (e.g., by rejecting it or capping it to a safe internal maximum).

Patch Analysis: What Did They Fix?

The provided code patch details (c8c2515936ef968dc8a3cecd9e79d1e69291e4bb) are for a test case (HTTP2Test.java), not the core server library fix itself. The change http2Client.setMaxRequestHeadersSize(2 * maxHeadersSize); in the test seems to adjust how the test client behaves, possibly to better test header size limits.

The actual fix for CVE-2025-1948 within the Jetty server code (org.eclipse.jetty.http2:jetty-http2-common) would involve adding a validation step where the server processes the SETTINGS_MAX_HEADER_LIST_SIZE parameter received from the client. Conceptually, the fix would look something like this (pseudo-code):

// Inside Jetty's HTTP/2 SETTINGS frame processing logic (conceptual)
// private static final long REASONABLE_MAX_HEADER_LIST_SIZE = /* some sane default, e.g., 32MB or configurable */;

public void processSettingsFrame(Map<Integer, Long> clientSettings) {
    Long clientMaxHeaderListSize = clientSettings.get(Http2Settings.MAX_HEADER_LIST_SIZE);

    if (clientMaxHeaderListSize != null) {
        if (clientMaxHeaderListSize > REASONABLE_MAX_HEADER_LIST_SIZE || clientMaxHeaderListSize <= 0) {
            // Log the attempt and either:
            // 1. Cap the value to the server's configured maximum
            this.effectiveMaxHeaderListSize = REASONABLE_MAX_HEADER_LIST_SIZE;
            // or 2. Treat it as a protocol error and close the connection
            // throw new Http2ProtocolException("Invalid SETTINGS_MAX_HEADER_LIST_SIZE");
        } else {
            this.effectiveMaxHeaderListSize = clientMaxHeaderListSize;
        }
    }

    // ... proceed to allocate buffers based on 'this.effectiveMaxHeaderListSize'
    // ByteBuffer headerBuffer = ByteBuffer.allocate((int) this.effectiveMaxHeaderListSize); // Now safe
}

The key is that the server no longer blindly trusts the client's value. It imposes its own sanity checks and limits, preventing the allocation of an absurdly large buffer.

Timeline: From Discovery to Disclosure

  • Discovery: The vulnerability was reported by Bjørn Seime of Vespa.ai. The exact date of discovery isn't public, but the report was made prior to public disclosure.
  • Vendor Notification: The Jetty team was notified, as evidenced by the GitHub issue and subsequent patch.
  • Patch Availability: Jetty version 12.0.17, containing the fix, was released.
  • Public Disclosure: The CVE and GitHub advisory were published on May 8, 2025.

Kudos to Bjørn Seime for finding and reporting this, and to the Jetty team for addressing it!

Lessons Learned: Trust, but Verify (Especially with Client Input!)

This vulnerability, while specific to Jetty and HTTP/2, teaches us some universal cybersecurity lessons:

  1. Never Trust Client Input for Resource Allocation: This is the golden rule. Any parameter from a client that influences how much memory, CPU, or disk space your server uses must be validated against strict, reasonable limits.
  2. Defense in Depth: While the primary fix is in the application, having JVM memory monitoring and alerting can help detect anomalous behavior (like rapid memory consumption) that might indicate an attack or a bug.
  3. Protocol Complexity Can Hide Bugs: HTTP/2 is more complex than HTTP/1.1. This complexity, while offering benefits, also increases the attack surface and the potential for implementation errors. Thorough testing of all protocol features is crucial.

One Key Takeaway: Even if a feature is part of a standard (like HTTP/2 settings), its implementation can introduce vulnerabilities. Always assume that clients (and sometimes even servers!) can and will send unexpected, malformed, or malicious data.

References and Further Reading

And there you have it – a deep dive into CVE-2025-1948. It's a great reminder that vigilance is key in the ever-evolving landscape of web technologies. So, go forth, patch your Jettys, and scrutinize those inputs!

What's the most surprising place you've seen an input validation vulnerability lead to serious consequences? Share your thoughts in the comments below!

Read more