Jetty 9.4.41 and nearby releases in the 9.4.x branch carry several documented vulnerabilities, most centered on HTTP/2 request handling and denial-of-service conditions, and the practical fix is straightforward: move to a current, actively patched Jetty release rather than treating any single 9.4.x point release as a stopping point. Eclipse Jetty is embedded inside a large share of the Java ecosystem — directly by teams who choose it, and indirectly as the servlet container inside tools like Solr, Cassandra's management interfaces, and countless internal services — which means a Jetty vulnerability often affects applications whose teams don't even know Jetty is running underneath them. This post covers what's actually been patched in the 9.4.x line, why HTTP/2 specifically has been a repeated source of issues, and how to know which Jetty version you should be on.
What Eclipse Jetty vulnerabilities have been documented in the 9.4.x branch?
The Jetty project has published a series of CVEs against the 9.4.x branch, with a recurring theme around HTTP/2 flow control, header handling, and how the server manages resources under malformed or excessive requests. Several of these advisories describe denial-of-service conditions where a specially crafted sequence of HTTP/2 frames — invalid header data, oversized or repeated settings frames, or requests that never properly complete — can exhaust server resources, causing high CPU usage or memory growth until the server becomes unresponsive. Others address more targeted issues, such as improper handling of certain malformed HTTP requests that could lead to request smuggling-adjacent behavior in front-end/back-end proxy configurations, or information disclosure through error handling that leaked more detail than intended. The Eclipse Foundation's official security advisories page and Jetty's GitHub security tab list the exact CVE identifiers and fixed-in versions for each 9.4.x release, and any environment still running an older point release in that branch should check that list directly rather than assuming a general "9.4.x" label means it's covered.
Why has HTTP/2 handling specifically been a source of Jetty vulnerabilities?
HTTP/2's binary framing model gives a server far more surface area for resource-exhaustion bugs than HTTP/1.1's simple text-based requests, and Jetty's HTTP/2 implementation has needed multiple rounds of hardening as a result. HTTP/2 multiplexes many logical requests over a single TCP connection using frames — headers, data, settings, priority, window-update — and a compliant server has to track flow-control state, stream concurrency limits, and header compression (HPACK) state per connection. Several Jetty advisories describe attackers exploiting edge cases in this bookkeeping: opening many streams and resetting them immediately (a pattern closely related to the industry-wide HTTP/2 Rapid Reset issue, CVE-2023-44487, that affected nearly every major HTTP/2 server implementation, Jetty included), or sending flow-control updates designed to force the server to buffer more than it should. This isn't unique to Jetty — Apache Tomcat, nginx, and major cloud load balancers all shipped their own HTTP/2 mitigations around the same period — but it does mean any Jetty deployment terminating HTTP/2 directly (rather than behind a proxy that normalizes it first) inherits this attack surface directly.
How do you know which Jetty version to patch to?
You determine the right Jetty version by checking your current version against Eclipse's official security advisories for the specific CVEs that apply to your branch, then upgrading to the earliest patched release in that same major line, or moving to a newer supported branch if your current branch has reached end of community support. Jetty 9.4.x itself is a long-lived branch that received security patches over an extended period, but Eclipse eventually shifts primary support to newer major versions (10.x, 11.x, and 12.x), so an application several point releases behind on 9.4.x may be carrying multiple unpatched CVEs simultaneously rather than just one. Because Jetty is frequently bundled inside other software — application servers, search platforms, monitoring tools — the practical first step is identifying every place Jetty actually runs in your environment, including transitively inside third-party JARs, before you can even start version-checking it. An SBOM that resolves down to embedded Jetty versions inside other artifacts, not just top-level declared dependencies, is usually the fastest way to get that inventory right.
What should you do if you can't upgrade Jetty immediately?
If an immediate Jetty upgrade isn't possible, reduce exposure by putting a hardened reverse proxy in front of it, disabling HTTP/2 where it isn't required, and applying resource limits at the connection level. A reverse proxy (nginx, HAProxy, a cloud load balancer) that terminates HTTP/2 and normalizes requests before they reach Jetty can absorb or rate-limit many of the malformed-frame patterns that trigger Jetty's denial-of-service issues, buying time without touching application code. Where HTTP/2 isn't a hard requirement for your clients, disabling it and falling back to HTTP/1.1 removes an entire vulnerability class from Jetty's exposed surface. Longer term, treat an unpatched Jetty instance the same as any other known-vulnerable dependency: track it explicitly, set a patch deadline, and don't let "it's just the servlet container" reasoning delay the upgrade the way it often does for infrastructure components that aren't part of the application code teams actively look at.
FAQ
Is there a specific "jetty 9.4.41 exploit" in the wild?
Jetty's 9.4.x branch has documented CVEs, mostly denial-of-service issues tied to HTTP/2 request and frame handling, rather than a single named exploit tied only to the 9.4.41 point release. Check Eclipse's official advisories for the exact CVE-to-version mapping that applies to your deployment.
Is Jetty vulnerable to the HTTP/2 Rapid Reset attack?
Jetty, like most major HTTP/2 server implementations, was affected by the industry-wide Rapid Reset issue (CVE-2023-44487) disclosed in 2023, and the project shipped mitigations addressing stream-reset abuse as part of its response.
How do I find out if Jetty is running in my environment if I didn't install it directly?
Jetty is commonly embedded inside other Java tools and platforms, so a manifest-level dependency check often misses it. Generate an SBOM that resolves nested and bundled dependencies, not just declared top-level ones, to catch Jetty running invisibly inside another application.
Should I upgrade to Jetty 10, 11, or 12 instead of staying on 9.4.x?
If your application's Java and Jakarta EE/Servlet API compatibility allows it, moving to a currently supported major branch is generally safer long-term than continuing to track individual patches on an older branch nearing the end of its support lifecycle — check Eclipse's support matrix for your specific stack before deciding.
How Safeguard Helps
Safeguard's SCA scanning resolves nested and transitive dependencies, so it catches Jetty running inside third-party tools and platforms, not just declarations in your own build file, and flags exactly which CVEs apply to the specific version found. Combined with DAST testing against live HTTP/2 endpoints, Safeguard can confirm whether a vulnerable Jetty instance is actually reachable and exploitable in your running environment, so patch prioritization is based on real exposure rather than version numbers alone.