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:

-...