GHSA-7p3p-8qv8-m2vh

#### 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:

- `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