CVE-2026-6790

What it actually does

Eclipse Jetty accepts HTTP/1, HTTP/2, and HTTP/3 requests without strictly enforcing that the request authority, such as an absolute-form URI authority or HTTP/2/HTTP/3 :authority pseudo-header, matches the Host header when both are present. This improper validation can let different components in the request-processing chain interpret the same request as targeting different hosts or ports. Depending on application and proxy behavior, this can affect URL generation, redirects, virtual host routing, reverse proxy target selection, audit logging, and security controls that rely on a trusted host value. The assessed impact is primarily integrity-related, because attackers may influence routing, generated links, or logs rather than directly execute code or read data.

Why it matters to the business

Organizations using Jetty-backed applications may be exposed to host-header confusion issues that can cause users to be redirected to attacker-controlled domains, requests to be routed to the wrong virtual host or backend, security monitoring to record misleading destinations, or proxy behavior to diverge from application behavior. This can undermine login flows, password-reset links, single sign-on redirects, tenant or site separation, and incident investigations. The CVSS score is moderate and EPSS is currently low, with no known CISA KEV listing or ransomware association, but internet-facing Jetty services should still be reviewed because exploitation requires no authentication and can be performed remotely.

How an attack unfolds

An attacker sends a crafted HTTP request to a Jetty service in which the authority value and the Host header identify different hosts or ports. For HTTP/1 this may involve an absolute-form request target combined with a conflicting Host header; for HTTP/2 or HTTP/3 it may involve a :authority value that differs from Host. Because vulnerable Jetty versions do not enforce equality between these values, downstream code may use one value for routing while application logic, redirect construction, proxying, or logging uses the other. The attacker then targets application paths that generate absolute URLs, perform login or redirect flows, select virtual hosts, or forward traffic to backend services. Successful exploitation can result in misleading redirects, host confusion, incorrect backend selection, or inaccurate logs that obscure the real request target.

How to fix it

Upgrade Eclipse Jetty to a version that enforces the current HTTP RFC requirement that request authority and Host match when both are present. No fixed version was provided in the input, so track Eclipse Jetty security advisories and apply the vendor-designated fixed release as soon as available. Until patched, mitigate by rejecting requests at the reverse proxy, load balancer, API gateway, or web application firewall when Host does not match the request authority, absolute-form URI authority, or HTTP/2/HTTP/3 :authority value. Configure edge infrastructure to normalize and pass a single trusted host value, strip conflicting host-related headers where possible, and only allow known expected hostnames. Applications should avoid constructing redirects or security-sensitive URLs directly from untrusted Host values; use an explicit configured public base URL instead. Review virtual host and reverse proxy rules to ensure routing decisions are not based on conflicting request fields.

How to confirm the fix worked

Confirm the installed Jetty version against the vendor advisory and verify that it includes the fix once a fixed release is available. Perform controlled tests against non-production or approved endpoints by sending requests where Host and the request authority differ; a remediated service should reject the request, typically with a 400-class response, rather than route or process it normally. Test HTTP/1, HTTP/2, and HTTP/3 if enabled. Validate that reverse proxies and load balancers also reject or normalize mismatched authority values before traffic reaches Jetty. Review application behavior for redirects, generated absolute URLs, and virtual host selection to ensure they use configured trusted hostnames rather than attacker-supplied headers.

Typical attack path

1. Identify a Jetty-hosted HTTP endpoint, especially one exposed to the internet or reachable through a reverse proxy/load balancer.
2. Determine whether the endpoint accepts requests where Host differs from the request authority, such as HTTP/2 :authority or an absolute-form HTTP/1 URI.
3. Send benign mismatch probes and observe whether the server rejects the request or processes it normally.
4. Target application functionality that depends on the perceived host, such as login redirects, password reset links, canonical URL generation, virtual host routing, or reverse proxy forwarding.
5. Use the mismatch to influence generated URLs, route requests unexpectedly, or create misleading audit/log records.
6. If applicable, combine the host-confusion behavior with phishing, cache poisoning, authentication-flow manipulation, or proxy misrouting techniques.

How to detect it

Look for evidence of requests containing conflicting host indicators. Useful log sources include reverse proxy logs, load balancer logs, WAF logs, CDN request logs, Jetty request logs, application access logs, authentication-flow logs, redirect logs, and packet captures for HTTP/1, HTTP/2, or HTTP/3 traffic. Investigate requests where the absolute URI host differs from the Host header, where HTTP/2 or HTTP/3 :authority differs from Host, where unexpected external domains appear in Host values, or where redirects are generated to domains not owned or expected by the organization. Also review virtual host routing logs for requests served by an unexpected site, backend proxy logs for unusual upstream target selection, and authentication or password-reset events where callback or redirect URLs contain unfamiliar hosts. Since exploitation may leave only malformed or unusual request metadata, detection depends heavily on whether both Host and authority values were logged at the edge.

• HTTP/2 :authority value differs from Host header
• HTTP/3 :authority value differs from Host header
• absolute-form request URI authority differs from Host header
• Host header contains an unexpected external domain
• Host header contains an unexpected port for the requested service
• multiple Host headers in a single request
• Host: 127.0.0.1
• Host: localhost
• Host: 0.0.0.0
• Host: [::1]
• GET http://
• POST http://
• PUT http://
• DELETE http://
• :authority: localhost
• :authority: 127.0.0.1

What your security team should do

• Inventory internet-facing and internal services that embed Eclipse Jetty, including products that bundle Jetty indirectly.
• Prioritize externally reachable Jetty services, authentication portals, SSO integrations, password-reset flows, reverse proxies, and multi-site or virtual-host deployments.
• Monitor Eclipse Jetty advisories and apply the vendor-fixed version as soon as it is published for the affected branch in use.
• Implement compensating controls at edge proxies or WAFs to reject requests where Host, absolute URI authority, and HTTP/2/HTTP/3 :authority do not match.
• Restrict accepted Host values to an allowlist of expected domains and ports wherever feasible.
• Review application code and framework configuration for URL generation, redirects, and callback construction that depend on inbound Host headers.
• Add logging for both Host and request authority values so mismatches can be detected and investigated.
• Hunt historical logs for unusual Host values, mismatched authority indicators, unexpected redirect destinations, and anomalous virtual host routing.
• Because EPSS is low and there is no KEV listing, treat this as moderate urgency overall, but elevate priority for public login, redirect, or proxying endpoints.