Eclipse Jetty: HTTP Authority/Host mismatch

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:

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

HTTP/3 rejection test:

• org.eclipse.jetty.http3.tests.HandlerClientServerTest#testRejectMismatchedHostHeaderAndAuthority

HTTP/3 exploitability test:

• org.eclipse.jetty.http3.tests.HandlerClientServerTest#testMismatchedHostHeaderAndAuthoritySplitsAuthorityFromHostHeader

Observed behavior:

• both rejection tests fail because Jetty returns 200 instead of 400
• both exploitability tests pass, confirming that Jetty exposes different host values to different layers

Project-Internal Evidence of Real Impact

Examples:

• jetty-openid uses Request.getServerName(request) to construct redirect URLs
• jetty-ee11-proxy uses the raw Host header when building Forwarded

This indicates that the issue is not merely theoretical: Jetty’s own ecosystem already contains code paths where different host sources are used for different purposes.

Affected Version

Confirmed affected version:

• 12.1.9-SNAPSHOT

Other versions may also be affected if they share the same HTTP/2 / HTTP/3 request construction and compliance-validation logic. I have not yet completed a historical version matrix and would recommend confirming exact affected ranges from Jetty’s branch history.

Suggested Fix

Recommend adding HTTP/2 and HTTP/3 validation equivalent to the existing HTTP/1.1 authority/Host consistency check:

• if both :authority and regular Host are present
  • normalize and compare them
  • if they do not match, reject the request with 400 Bad Request
  • route the failure through the existing MISMATCHED_AUTHORITY compliance mechanism

Also adding explicit HTTP/2 and HTTP/3 regression coverage for this case.

Disclosure Status

• not publicly disclosed
• no public issue filed
• shared only privately with the Jetty security contacts