Source: jetty9 Version: 9.4.58-2 X-Debbugs-CC: [email protected] Severity: grave Tags: security upstream
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
