CVE-2026-6790: 
Java vulnerability analysis and mitigation

CVE-2026-6790 is an HTTP Authority/Host mismatch vulnerability in Eclipse Jetty that allows unauthenticated network attackers to send requests where the request authority (:authority pseudo-header) and the Host header contain different values, violating RFC 9110 and RFC 9112. Affected versions span Eclipse Jetty 9.4.0–9.4.60, 10.0.0–10.0.28, 11.0.0–11.0.28, 12.0.0–12.0.34, and 12.1.0–12.1.8. The vulnerability was published on July 14, 2026, with a GitHub Advisory published July 22, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory).

The root cause is improper input validation (CWE-20): Jetty already enforces authority/Host consistency on HTTP/1.1 connections via an explicit check in HttpConnection.java, but equivalent validation is absent on the HTTP/2 and HTTP/3 code paths. On HTTP/2 and HTTP/3, the :authority pseudo-header is parsed into URI/authority state while the Host header is preserved as a normal request header, and the two values are never compared for consistency — the MISMATCHED_AUTHORITY compliance violation is defined in HttpCompliance.java but not enforced on H2/H3 server entry points (HttpStreamOverHTTP2.java, HttpStreamOverHTTP3.java). This allows a single request to carry two conflicting host identities: logic using Request.getServerName() sees :authority, while logic reading raw headers sees Host. The GitHub Advisory includes reproduction steps using a local Jetty HTTP/2 or HTTP/3 test server, confirming that crafted requests return HTTP 200 instead of the expected 400 Bad Request (Github Advisory).

Successful exploitation enables host header injection attacks that can result in malicious redirect or callback URL construction (particularly on login/logout pages), bypass of host-based access controls, virtual host or multi-tenant isolation failures, reverse proxy misrouting, and log/audit record poisoning. Jetty's own ecosystem is demonstrably affected: jetty-openid uses Request.getServerName() to construct redirect URLs, while jetty-ee11-proxy uses the raw Host header when building Forwarded headers, meaning the confusion is not merely theoretical. The vulnerability has no confidentiality or availability impact but poses a low-to-moderate integrity risk depending on deployment context (Github Advisory).

There is no evidence of public proof-of-concept exploit code or active in-the-wild exploitation at this time, and the vulnerability has not been added to the CISA Known Exploited Vulnerabilities catalog. The attack is network-accessible, requires no authentication or user interaction, and is automatable, lowering the bar for exploitation. The EPSS score is approximately 0.196% (10th percentile), indicating a low near-term exploitation probability (Github Advisory).

1. Reconnaissance: Identify internet-facing Eclipse Jetty servers running HTTP/2 or HTTP/3 on affected versions (9.4.0–9.4.60, 10.0.0–10.0.28, 11.0.0–11.0.28, 12.0.0–12.0.34, 12.1.0–12.1.8) using tools such as Shodan or Censys, or by inspecting Server response headers.
2. Craft a conflicting request: Construct an HTTP/2 or HTTP/3 request where the :authority pseudo-header is set to the legitimate target host (e.g., legitimate.example.com) and the Host header is set to an attacker-controlled value (e.g., evil.attacker.com).
3. Submit the request: Send the crafted request to a vulnerable Jetty endpoint — for example, a login page or OAuth callback endpoint — that constructs redirect URLs or performs host-based routing decisions.
4. Exploit the split identity: Because Jetty exposes different host values to different layers, application logic using Request.getServerName() will see the :authority value while raw-header-reading code sees the attacker-supplied Host value. This can cause the server to generate a redirect to evil.attacker.com, misroute the request to an unintended virtual host, or write misleading entries to audit logs.
5. Achieve objective: Depending on the application, the attacker may harvest credentials via a phishing redirect, bypass host-based ACLs, or poison cache/log entries (Github Advisory).

• Network: HTTP/2 or HTTP/3 requests where the :authority pseudo-header and the Host header contain different, non-matching values; unexpected outbound redirects from the Jetty server to external or attacker-controlled domains.
• Logs: Access log entries showing requests to login, logout, or OAuth callback endpoints with a Host header value that differs from the expected server hostname; audit records referencing unexpected hostnames in redirect URLs.
• Application Behavior: Redirect responses (HTTP 301/302/307) pointing to domains not in the application's configured allowed-redirect list; Forwarded or X-Forwarded-Host headers in downstream proxy logs containing unexpected hostnames.

Upgrade Eclipse Jetty to a patched version: 9.4.61 or later, 10.0.29 or later, 11.0.29 or later, 12.0.35 or later, or 12.1.9 or later. If immediate patching is not feasible, implement strict Host header validation at the reverse proxy or load balancer layer to ensure the Host header matches the expected server authority before traffic reaches Jetty, effectively blocking mismatched requests upstream. Applications that use Request.getServerName() or raw Host headers for security-sensitive decisions (access control, redirect URL construction, multi-tenant routing) should be reviewed and hardened independently of the Jetty patch (Github Advisory).