CVE-2026-6790
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk24th percentile - higher than 24% of all known CVEs
Summary
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 the value provided in the Host header (if present). This mismatch can cause problems such as incorrect URI construction, virtual host selection, reverse proxying, misleading logs, and others.
Risk Assessment
The lack of validation may allow an attacker to manipulate the Host header, leading to redirects to malicious sites, unauthorized access to virtual hosts, or incorrect request routing through reverse proxies, increasing the risk of security breaches and data integrity issues.
Recommendation
It is recommended to immediately update Eclipse Jetty to a version that enforces the match between request authority and Host header as per RFC 9110 and 9112. If an update is not possible, consider implementing temporary firewall or proxy rules to filter mismatched requests.
Other vulnerabilities in Eclipse Jetty
See all- CVE-2015-2080High
The exception handling code in Eclipse Jetty before version 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, known as JetLeak.
- CVE-2026-10050Critical
In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode passwords as bytes, silently replacing characters outside that charset with '?'.
- CVE-2026-19864Medium
In Eclipse Jetty, 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-18662Medium
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-18660High
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-18659Medium
In Eclipse Jetty, across various versions of jetty-security, 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-77711High
In Jetty's HttpClient, when a request is made 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 and re-sends the request with the Proxy-Authentication header, which reaches the server and exposes the proxy credentials to it.
- CVE-2026-76184High
In Eclipse Jetty, HttpClient may receive a redirect of the form /secure/../evil. If an attacker controls the redirects, HttpClient matches authentication credentials against /secure rather than normalizing the path to /evil, and therefore follows the redirect sending the Authorization header for /secure to /evil.
- CVE-2026-76182Medium
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-18661High
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 applied if the web.xml had more than one url-pattern for a servlet and a security-constraint applied to only some of those url-pattern definitions.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

