Eclipse Jetty 9.4
Eclipse Jetty 9.4
The Eclipse Jetty 9.4 reached end of service life on Aug 14, 2025 — Eclipse Jetty no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.
24/7 engineers own your Eclipse Jetty 9.4 incidents end to end.
Mitigation and patch-around guidance when the vendor no longer ships fixes.
Controls evidence and documentation that keep auditors satisfied.
Specifications
- product
- eclipse-jetty
- release
- 9.4
- product Label
- Eclipse Jetty
- release Label
- 9.4
- codename
- lts
- latest Version
- 9.4.58.v20250814
- release Date
- 2016-12-07
- maintained
- true
- source Url
- https://endoflife.date/eclipse-jetty
Lifecycle Dates
- End of Service Life
- Aug 14, 2025
- Last OEM Support
- Jun 1, 2022
OEM vs. 3rd Party Support
See how third-party support compares to the vendor contract for Eclipse Jetty 9.4 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.
| Feature | OEM Support | 3rd Party Support |
|---|---|---|
| Post-EOSL Support | ||
| Break/Fix Support | Until EOSL | |
| 24/7 Monitoring | ||
| Vulnerability Scanning & Remediation | ||
| Managed Operations | ||
| Procedure & Configuration Review | ||
| Compliance & Audit Documentation | Limited | |
| Discounted Migration to Other Platforms |
Why Choose 3rd Party Support for Eclipse Jetty 9.4?
Vulnerability Remediation
Scanning, mitigation and patch-around guidance for Eclipse Jetty 9.4 when the vendor no longer ships fixes.
Compliance Maintenance
Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.
24/7 Expert Support
Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.
Eclipse Jetty 9.4 Support: Frequently Asked Questions
Is the Eclipse Jetty 9.4 still supported?
Eclipse Jetty ended support for the Eclipse Jetty 9.4 on Aug 14, 2025 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.
When is the Eclipse Jetty 9.4 end of service life (EOSL) date?
Eclipse Jetty lists the end of service life for the Eclipse Jetty 9.4 as Aug 14, 2025.
Can I keep using the Eclipse Jetty 9.4 after its EOSL date?
Yes. EOSL means Eclipse Jetty stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.
How much does third-party support for the Eclipse Jetty 9.4 cost?
Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.
Known Vulnerabilities Affecting Eclipse Jetty 9.4
38 published CVEs affect the Eclipse Jetty 9.4, including 18 rated critical or high severity. Eclipse Jetty no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.
| CVE | Severity | CVSS | Published | Summary |
|---|---|---|---|---|
| CVE-2017-7658 | CRITICAL | 9.8 | Jun 26, 2018 | In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermed |
| CVE-2017-7657 | CRITICAL | 9.8 | Jun 26, 2018 | In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allo |
| CVE-2019-17638 | CRITICAL | 9.4 | Jul 9, 2020 | In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with other data. Thread1 then |
| CVE-2018-12538 | HIGH | 8.8 | Jun 22, 2018 | In Eclipse Jetty versions 9.4.0 through 9.4.8, when using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem's storage for the FileSessionDataStore. |
| CVE-2026-10050 | HIGH | 8.7 | Aug 4, 2026 | In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes. This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical reasons. If the password contains characters that cannot be represented in ISO-8859-1, they are silently replaced by `?`. This happens with passwords that contain Chinese, Cyrillic or Greek characters, for example: `αβ123` converts t |
| CVE-2025-5115 | HIGH | 7.7 | Aug 20, 2025 | In Eclipse Jetty, versions <=9.4.57, <=10.0.25, <=11.0.25, <=12.0.21, <=12.1.0.alpha2, an HTTP/2 client may trigger the server to send RST_STREAM frames, for example by sending frames that are malformed or that should not be sent in a particular stream state, therefore forcing the server to consume resources such as CPU and memory. For example, a client can open a stream and then send WINDOW_UPDATE frames with window size increment of 0, which is illegal. Per specification https://www.rfc-edi |
| CVE-2024-22201 | HIGH | 7.5 | Feb 26, 2024 | Jetty is a Java based web server and servlet engine. An HTTP/2 SSL connection that is established and TCP congested will be leaked when it times out. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The vulnerability is patched in 9.4.54, 10.0.20, 11.0.20, and 12.0.6. |
| CVE-2023-36478 | HIGH | 7.5 | Oct 10, 2023 | Eclipse Jetty provides a web server and servlet container. In versions 11.0.0 through 11.0.15, 10.0.0 through 10.0.15, and 9.0.0 through 9.4.52, an integer overflow in `MetaDataBuilder.checkSize` allows for HTTP/2 HPACK header values to exceed their size limit. `MetaDataBuilder.java` determines if a header name or value exceeds the size limit, and throws an exception if the limit is exceeded. However, when length is very large and huffman is true, the multiplication by 4 in line 295 will overflo |
| CVE-2023-44487 | HIGH | 7.5 | Oct 10, 2023 | The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023. |
| CVE-2022-2048 | HIGH | 7.5 | Jul 7, 2022 | In Eclipse Jetty HTTP/2 server implementation, when encountering an invalid HTTP/2 request, the error handling has a bug that can wind up not properly cleaning up the active connections and associated resources. This can lead to a Denial of Service scenario where there are no enough resources left to process good requests. |
| CVE-2021-28165 | HIGH | 7.5 | Apr 1, 2021 | In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame. |
| CVE-2018-12545 | HIGH | 7.5 | Mar 27, 2019 | In Eclipse Jetty version 9.3.x and 9.4.x, the server is vulnerable to Denial of Service conditions if a remote client sends either large SETTINGs frames container containing many settings, or many small SETTINGs frames. The vulnerability is due to the additional CPU and memory allocations required to handle changed settings. |
| CVE-2017-7656 | HIGH | 7.5 | Jun 26, 2018 | In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), HTTP/0.9 is handled poorly. An HTTP/1 style request line (i.e. method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HT |
| CVE-2017-9735 | HIGH | 7.5 | Jun 16, 2017 | Jetty through 9.4.x is prone to a timing channel in util/security/Password.java, which makes it easier for remote attackers to obtain access by observing elapsed times before rejection of incorrect passwords. |
| CVE-2026-2332 | HIGH | 7.4 | Apr 14, 2026 | In Eclipse Jetty, the HTTP/1.1 parser is vulnerable to request smuggling when chunk extensions are used, similar to the "funky chunks" techniques outlined here: * https://w4ke.info/2025/06/18/funky-chunks.html * https://w4ke.info/2025/10/29/funky-chunks-2.html Jetty terminates chunk extension parsing at \r\n inside quoted strings instead of treating this as an error. POST / HTTP/1.1 Host: localhost Transfer-Encoding: chunked 1;ext="val X 0 GET /smuggled HTTP/1.1 ... Note how |
| CVE-2026-5795 | HIGH | 7.4 | Apr 8, 2026 | In Eclipse Jetty, the class JASPIAuthenticator initiates the authentication checks, which set two ThreadLocal variable. Upon returning from the initial checks, there are conditions that cause an early return from the JASPIAuthenticator code without clearing those ThreadLocals. A subsequent request using the same thread inherits the ThreadLocal values, leading to a broken access control and privilege escalation. |
| CVE-2024-13009 | HIGH | 7.2 | May 8, 2025 | In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests. |
| CVE-2020-27216 | HIGH | 7.0 | Oct 23, 2020 | In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory us |
| CVE-2019-17632 | MEDIUM | 6.1 | Nov 25, 2019 | In Eclipse Jetty versions 9.4.21.v20190926, 9.4.22.v20191022, and 9.4.23.v20191118, the generation of default unhandled Error response content (in text/html and text/json Content-Type) does not escape Exception messages in stacktraces included in error output. |
| CVE-2019-10241 | MEDIUM | 6.1 | Apr 22, 2019 | In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and 9.4.15 and older, the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents. |
Showing the 20 most severe of 38 known CVEs.
Get Third Party Support