CVE-2026-6790

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.

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.

Summary

Jetty currently accepts HTTP/2 and HTTP/3 requests where the regular Host header and the pseudo-header :authority do not match. As a result, the same request can carry two different host identities through Jetty:

• logic based on HttpURI / Request.getServerName(request) uses :authority
• logic based on raw request headers continues to use Host

This creates a host/authority confusion condition that can break security assumptions in higher layers.

Jetty already performs an explicit authority/Host consistency check on the HTTP/1.1 path, but equivalent validation is missing on the HTTP/2 and HTTP/3 paths.

Security Impact

This issue is not inherently remote code execution, but it can become security-relevant in deployments that rely on the request host for security-sensitive decisions, including:

• host-based access control
• virtual host isolation
• multi-tenant routing by hostname
• login/logout/callback URL construction
• reverse proxy and forwarded-header trust chains
• auditing, cache keys, and absolute URL generation

Potential consequences include:

• bypass of host-based ACLs
• virtual host or tenant isolation failures
• incorrect or attacker-influenced redirect/callback targets
• inconsistent proxy/downstream interpretation of the original target host
• misleading logs and audit records

Technical Root Cause

1. On the HTTP/2 and HTTP/3 metadata builder paths:

• :authority is parsed separately into authority/URI state
• Host is preserved as a normal request header
• the two values are not compared for consistency

2. On the HTTP/2 and HTTP/3 server entry paths:

• Jetty calls ComplianceUtils.verify(httpCompliance, requestMetaData, listener)
• this verification does not enforce MISMATCHED_AUTHORITY

3. On the HTTP/1.1 path:

• Jetty explicitly checks whether authority and Host match
• mismatches are rejected by default

Relevant Code Locations

HTTP/2 metadata builder:

• jetty-core/jetty-http2/jetty-http2-hpack/src/main/java/org/eclipse/jetty/http2/hpack/internal/MetaDataBuilder.java

HTTP/3 metadata builder:

• jetty-core/jetty-http3/jetty-http3-qpack/src/main/java/org/eclipse/jetty/http3/qpack/internal/metadata/MetaDataBuilder.java

HTTP/2 server entry:

• jetty-core/jetty-http2/jetty-http2-server/src/main/java/org/eclipse/jetty/http2/server/internal/HttpStreamOverHTTP2.java

HTTP/3 server entry:

• jetty-core/jetty-http3/jetty-http3-server/src/main/java/org/eclipse/jetty/http3/server/internal/HttpStreamOverHTTP3.java

Shared HTTP compliance verification:

• jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/ComplianceUtils.java

HTTP/1.1 authority/Host consistency check:

• jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpConnection.java

Defined but not enforced on H2/H3:

• jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpCompliance.java
• violation: MISMATCHED_AUTHORITY

Reproduction

I reproduced this on local Jetty 12.1.9-SNAPSHOT source.

Minimal reproduction steps:

1. Start a Jetty HTTP/2 or HTTP/3 test server.
2. Send a request with:
   • :authority = localhost:<port>
   • Host = evil.example:<port>
3. In the request handler, inspect both:
   • Request.getServerName(request)
   • request.getHeaders().get(HttpHeader.HOST)
4. Observe whether Jetty rejects the request or allows both values to remain visible. Observed result:
   • HTTP/2: request is accepted and returns 200
   • HTTP/3: request is accepted and returns 200
   • the server can observe both:
     • serverName=localhost
     • hostHeader=evil.example:<port>

This shows that a single attacker-controlled request can preserve two conflicting host interpretations inside Jetty.

Tests Used

HTTP/2 rejection test:

• org.eclipse.jetty.http2.tests.HTTP2Test#testRejectMismatchedHostHeaderAndAuthority

HTTP/2 exploitability test:

-…

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.

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.

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.