High Jetty CVEs
28 CVEs, 2 exploited, 1 protected by Waratek
Overview 28 matches · 1 protected · 2 exploited · 1 CISA KEV · 3 public PoC · 3 EPSS ≥ 0.5
Protected by Waratek
1
3.6%
Rule in development
0
0.0%
Mitigation candidate
2
7.1%
No exploit published
25
89.3%
blocked by ARMR today
1
3.6%
partly blocked
0
0.0%
not blocked
27
96.4%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 5 / year
20071
No exploit published1
High1
not blocked1
No public exploit1
20080
20090
20101
No exploit published1
High1
not blocked1
No public exploit1
20110
20120
20130
20140
20150
20162
Mitigation candidate1
No exploit published1
High2
not blocked2
Working exploit published1
No public exploit1
20172
No exploit published2
High2
not blocked2
No public exploit2
20183
No exploit published3
High3
not blocked3
No public exploit3
20192
No exploit published2
High2
not blocked2
No public exploit2
20201
No exploit published1
High1
not blocked1
No public exploit1
20211
No exploit published1
High1
not blocked1
Forecast only1
20222
No exploit published2
High2
not blocked2
No public exploit2
20232
Mitigation candidate1
No exploit published1
High2
not blocked2
Exploited1
No public exploit1
20242
No exploit published2
High2
not blocked2
Proof of concept only1
No public exploit1
20254
Protected by Waratek1
No exploit published3
High4
blocked by ARMR today1
not blocked3
Exploited1
No public exploit3
20265
No exploit published5
High5
not blocked5
Proof of concept only1
No public exploit4
2008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-10050 | High | 2026-08-04 | No exploit published | Proof of concept only | 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 to `??123`. An attacker can send a request with a digest `Authorization` header crafted with a password made of only `?` characters; the server would match any password of the same length that contains non-ISO-8859-1 characters. Recent HTTP Digest [RFC-7616](https://datatracker.ietf.org/doc/html/rfc7616) supports a `charset` parameters that defaults to UTF-8 that allows for correct encoding/decoding of passwords. |
| CVE-2024-7708 | High | 2026-07-14 | No exploit published | No public exploit | For requests that have a body, but reading the body may end up in reading 0 bytes, there is a buffer leak. This is particularly the case for 100-Continue, but any request where the network is slow can leak. |
| CVE-2026-40984 | High | 2026-06-09 | No exploit published | No public exploit | In Micrometer, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Affected versions: micrometer-core 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18; 1.9.0 through 1.9.17. micrometer-jetty11 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18. micrometer-jetty12 1.16.0 through 1.16.5; 1.15.0 through 1.15.11; 1.14.0 through 1.14.15; 1.13.0 through 1.13.18. |
| CVE-2026-5795 | High | 2026-04-08 | No exploit published | No public exploit | 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-2026-1605 | High | 2026-03-05 | No exploit published | No public exploit | In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed. This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak. |
| CVE-2025-55749 | High | 2025-12-01 | Protected by Waratek | Exploited | XWiki is an open-source wiki software platform. From 16.7.0 to 16.10.11, 17.4.4, or 17.7.0, in an instance which is using the XWiki Jetty package (XJetty), a context is exposed to statically access any file located in the webapp/ folder. It allows accessing files which might contains credentials. Fixed in 16.10.11, 17.4.4, and 17.7.0. |
| CVE-2025-5115 | High | 2025-08-20 | No exploit published | No public exploit | 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-editor.org/rfc/rfc9113.html#name-window_update , the server should send a RST_STREAM frame. The client can now open another stream and send another bad WINDOW_UPDATE, therefore causing the server to consume more resources than necessary, as this case does not exceed the max number of concurrent streams, yet the client is able to create an enormous amount of streams in a short period of time. The attack can be performed with other conditions (for example, a DATA frame for a closed stream) that cause the server to send a RST_STREAM frame. Links: * https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h |
| CVE-2025-1948 | High | 2025-05-08 | No exploit published | No public exploit | In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. 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, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting. |
| CVE-2024-13009 | High | 2025-05-08 | No exploit published | No public exploit | 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-2024-9823 | High | 2024-10-14 | No exploit published | No public exploit | There exists a security vulnerability in Jetty's DosFilter which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack on the server using DosFilter. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory finally. |
| CVE-2024-22201 | High | 2024-02-26 | No exploit published | Proof of concept only | 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-44487 | High | 2023-10-10 | Mitigation candidate | Exploited | 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-2023-36478 | High | 2023-10-10 | No exploit published | No public exploit | 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 overflow, and length will become negative. `(_size+length)` will now be negative, and the check on line 296 will not be triggered. Furthermore, `MetaDataBuilder.checkSize` allows for user-entered HPACK header value sizes to be negative, potentially leading to a very large buffer allocation later on when the user-entered size is multiplied by 2. This means that if a user provides a negative length value (or, more precisely, a length value which, when multiplied by the 4/3 fudge factor, is negative), and this length value is a very large positive number when multiplied by 2, then the user can cause a very large buffer to be allocated on the server. Users of HTTP/2 can be impacted by a remote denial of service attack. The issue has been fixed in versions 11.0.16, 10.0.16, and 9.4.53. There are no known workarounds. |
| CVE-2022-2191 | High | 2022-07-07 | No exploit published | No public exploit | In Eclipse Jetty versions 10.0.0 thru 10.0.9, and 11.0.0 thru 11.0.9 versions, SslConnection does not release ByteBuffers from configured ByteBufferPool in case of error code paths. |
| CVE-2022-2048 | High | 2022-07-07 | No exploit published | No public exploit | 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 | 2021-04-01 | No exploit published | Forecast only | 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-2020-27216 | High | 2020-10-23 | No exploit published | No public exploit | 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 used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. |
| CVE-2009-5045 | High | 2019-11-06 | No exploit published | No public exploit | Dump Servlet information leak in jetty before 6.1.22. |
| CVE-2018-12545 | High | 2019-03-27 | No exploit published | No public exploit | 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-2018-8038 | High | 2018-07-05 | No exploit published | No public exploit | Versions of Apache CXF Fediz prior to 1.4.4 do not fully disable Document Type Declarations (DTDs) when either parsing the Identity Provider response in the application plugins, or in the Identity Provider itself when parsing certain XML-based parameters. |
| CVE-2017-7656 | High | 2018-06-26 | No exploit published | No public exploit | 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 HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response. |
| CVE-2018-12538 | High | 2018-06-22 | No exploit published | No public exploit | 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-2017-9735 | High | 2017-06-16 | No exploit published | No public exploit | 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-2017-7661 | High | 2017-05-16 | No exploit published | No public exploit | Apache CXF Fediz ships with a number of container-specific plugins to enable WS-Federation for applications. A CSRF (Cross Style Request Forgery) style vulnerability has been found in the Spring 2, Spring 3, Jetty 8 and Jetty 9 plugins in Apache CXF Fediz prior to 1.4.0, 1.3.2 and 1.2.4. |
| CVE-2015-2080 | High | 2016-10-07 | Mitigation candidate | Working exploit published | The exception handling code in Eclipse Jetty before 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, aka JetLeak. |
| CVE-2015-5348 | High | 2016-04-15 | No exploit published | No public exploit | Apache Camel 2.6.x through 2.14.x, 2.15.x before 2.15.5, and 2.16.x before 2.16.1, when using (1) camel-jetty or (2) camel-servlet as a consumer in Camel routes, allow remote attackers to execute arbitrary commands via a crafted serialized Java object in an HTTP request. |
| CVE-2009-4611 | High | 2010-01-13 | No exploit published | No public exploit | Mort Bay Jetty 6.x through 6.1.22 and 7.0.0 writes backtrace data without sanitizing non-printable characters, which might allow remote attackers to modify a window's title, or possibly execute arbitrary commands or overwrite files, via an HTTP request containing an escape sequence for a terminal emulator, related to (1) a string value in the Age parameter to the default URI for the Cookie Dump Servlet in test-jetty-webapp/src/main/java/com/acme/CookieDump.java under cookie/, (2) an alphabetic value in the A parameter to jsp/expr.jsp, or (3) an alphabetic value in the Content-Length HTTP header to an arbitrary application. |
| CVE-2007-5614 | High | 2007-12-05 | No exploit published | No public exploit | Mortbay Jetty before 6.1.6rc1 does not properly handle "certain quote sequences" in HTML cookie parameters, which allows remote attackers to hijack browser sessions via unspecified vectors. |