Hi,
The following vulnerabilities were published for jetty9.
CVE-2025-11143[0]:
| The Jetty URI parser has some key differences to other common
| parsers when evaluating invalid or unusual URIs. Differential
| parsing of URIs in systems using multiple components may result in
| security by-pass. For example a component that enforces a black list
| may interpret the URIs differently from one that generates a
| response. At the very least, differential parsing may divulge
| implementation details.
CVE-2026-10050[1]:
| 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-2026-10051[2]:
| In Eclipse Jetty, a first HTTP/1.1 request with trailers causes the
| server to retain the trailers in subsequent requests performed over
| the same connection. Subsequent request that do not have trailers
| report the trailers of the first request. Subsequent request that do
| have trailers report the union of trailers of the first request and
| the current request.
CVE-2026-12611[3]:
| A client may issue HTTP/2 requests to a Jetty server that result in
| blocking writes that are never unblocked, eventually causing all
| threads to be blocked and the whole server to become unresponsive.
| This is caused by a race condition in the server when handling
| RST_STREAM frames and GOAWAY frames sent by the client. The race
| condition "resets" the HTTP2Flusher.terminated, previously set to a
| non-null value, to the null value, allowing entries to be enqueued
| in the flusher that however will never be processed. These
| unprocessed entries are the ones that would unblock the write-
| blocked threads.
CVE-2026-18659[4]:
| In Eclipse Jetty, across various versions of `jetty-security`, and
| `jetty-eeN-security`, and `jetty-eeN-servlet`, the Jakarta Spec
| constraints defined as `http-method-omission` can be bypassed by
| using substrings of the defined HTTP Methods.
CVE-2026-18660[5]:
| In Eclipse Jetty, across various versions of `jetty-server`, and
| `jetty-proxy`, the host whitelist/blacklist is case-sensitive, and
| would allow hosts through that only differ by case.
CVE-2026-18661[6]:
| In Eclipse Jetty, across various versions of `jetty-annotations`,
| and `jetty-eeN-annotations`, the Jakarta Spec authoritative url-
| pattern rules for mixed `@ServletSecurity` annotation, and `web.xml`
| defined `security-constraint` on the same `url-pattern` were not
| being applied if the `web.xml` had more than 1 `url-pattern` for a
| servlet, and had a `security-constraint` applying to only some of
| those `url-pattern` definitions.
CVE-2026-18662[7]:
| In Eclipse Jetty, across various versions of `jetty-security`, and
| `jetty-eeN-security`, two or more security constraints with the same
| http-method-omission set, and no url-patterns, are not combined
| properly per Jakarta Servlet Spec. Resulting in later http-
| method-omission sets overriding previous constraints with the same
| http-method-omission set.
CVE-2026-19203[8]:
| A client may issue specially crafted HTTP/1.1 chunked requests to a
| Jetty server that cause Jetty and an intermediary proxy to interpret
| different request boundaries, potentially resulting in HTTP request
| smuggling. This is caused by Jetty accepting a lone LF character
| as a terminator in parts of chunked request parsing. Depending on
| the Jetty version and configured HTTP compliance mode, this may
| occur in chunk extensions, chunk data termination, or trailer
| termination.
CVE-2026-19864[9]:
| Eclipse Jetty's `SessionAuthentication` retains authentication
| credentials in a serializable object. When the credentials contain a
| plaintext password and the authenticated session is persisted to a
| session data store, the password may consequently be written to
| persistent storage in plaintext. An attacker with sufficient
| privileges to read the persisted session data may obtain the
| plaintext passwords of authenticated users.
CVE-2026-2332[10]:
| 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 the chunk extension does not close the double
| quotes, and it is able to inject a smuggled request.
CVE-2026-6790[11]:
| In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is
| no strict check that the request authority (host and port) matches
| what provided in the Host header (if present). This was not
| enforced in earlier HTTP RFC (for example, in RFC 2616), but it is
| in the latest RFC (9110 and 9112). This mismatch can cause a
| number of problems that may be classified as vulnerabilities such
| as: * URI constructions (for example, for
| redirects -- this is typical for login pages) *
| Virtual host selection * Reverse proxying *
| Misleading logs * Etc. Given that the
| latest RFCs require that request authority and Host header must
| match, Jetty should enforce this invariant.
CVE-2026-76182[12]:
| In Eclipse Jetty, `TryPathsHandler` and `TryFilesFilter` can be
| configured to forward requests to template URIs such as
| `index?p=$path`, where `$path` is the request path in context.
| However, URI paths may contain characters that are reserved in URI
| queries so that a path of `/s&a=1` when applied to the template
| becomes `index?p=/s&a=1`, which is interpreted as 2 query
| parameters: `p=/s` and `a=1`, rather than just one query parameter
| `p` whose value is `/s&a=1`.
CVE-2026-76184[13]:
| In Eclipse Jetty, HttpClient may receive a redirect of the form:
| ``` /secure/../evil ``` If an attacker is able to control
| the redirects, then HttpClient matches authentication credentials
| against `/secure` rather than normalizing the path to `/evil`, and
| will therefore follow the redirect sending the `Authorization`
| header for `/secure` to `/evil`. This also mean that the attacker
| must have an evil application deployed on the same domain as the
| target.
CVE-2026-77711[14]:
| When Jetty's `HttpClient` make a request to a server through a
| forward proxy, the server may reply with a 407 (Proxy Authentication
| Required). The client mistakenly interprets the 407 as coming
| from the proxy, so it re-sends the request with the `Proxy-
| Authentication` header, which arrives to the server, that now has
| access to the proxy credentials.
CVE-2026-8384[15]:
| In Eclipse Jetty, an HTTP URI of this form:
| /public;/../admin/secret.txt results in an unresolved path
| of: /public/../admin/secret.txt instead of the
| expected: /admin/secret.txt Jetty itself is not
| affected, as it will not serve the secret.txt file because it will
| not pass the alias checker (only resolved resources are served).
| However, web applications that rely on resolved paths being provided
| by Jetty may be confused when receiving an unresolved path.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2025-11143
https://www.cve.org/CVERecord?id=CVE-2025-11143
[1] https://security-tracker.debian.org/tracker/CVE-2026-10050
https://www.cve.org/CVERecord?id=CVE-2026-10050
[2] https://security-tracker.debian.org/tracker/CVE-2026-10051
https://www.cve.org/CVERecord?id=CVE-2026-10051
[3] https://security-tracker.debian.org/tracker/CVE-2026-12611
https://www.cve.org/CVERecord?id=CVE-2026-12611
[4] https://security-tracker.debian.org/tracker/CVE-2026-18659
https://www.cve.org/CVERecord?id=CVE-2026-18659
[5] https://security-tracker.debian.org/tracker/CVE-2026-18660
https://www.cve.org/CVERecord?id=CVE-2026-18660
[6] https://security-tracker.debian.org/tracker/CVE-2026-18661
https://www.cve.org/CVERecord?id=CVE-2026-18661
[7] https://security-tracker.debian.org/tracker/CVE-2026-18662
https://www.cve.org/CVERecord?id=CVE-2026-18662
[8] https://security-tracker.debian.org/tracker/CVE-2026-19203
https://www.cve.org/CVERecord?id=CVE-2026-19203
[9] https://security-tracker.debian.org/tracker/CVE-2026-19864
https://www.cve.org/CVERecord?id=CVE-2026-19864
[10] https://security-tracker.debian.org/tracker/CVE-2026-2332
https://www.cve.org/CVERecord?id=CVE-2026-2332
[11] https://security-tracker.debian.org/tracker/CVE-2026-6790
https://www.cve.org/CVERecord?id=CVE-2026-6790
[12] https://security-tracker.debian.org/tracker/CVE-2026-76182
https://www.cve.org/CVERecord?id=CVE-2026-76182
[13] https://security-tracker.debian.org/tracker/CVE-2026-76184
https://www.cve.org/CVERecord?id=CVE-2026-76184
[14] https://security-tracker.debian.org/tracker/CVE-2026-77711
https://www.cve.org/CVERecord?id=CVE-2026-77711
[15] https://security-tracker.debian.org/tracker/CVE-2026-8384
https://www.cve.org/CVERecord?id=CVE-2026-8384
Regards,
Salvatore