GHSA-7p3p-8qv8-m2vh: Eclipse Jetty: HTTP Authority/Host mismatch

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/htt