medium

CVE-2026-6790

Maven · org.eclipse.jetty:jetty-server

Summary

Eclipse Jetty: HTTP Authority/Host mismatch

Severity
medium
CVSS
5.3
EPSS
0.3% (p24)
CWE
CWE-20
Also known as
GHSA-7p3p-8qv8-m2vh
Published
2026-07-22
Updated
2026-07-22

Advisory details

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:

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:

Potential consequences include:

Technical Root Cause

  1. On the HTTP/2 and HTTP/3 metadata builder paths:
  1. On the HTTP/2 and HTTP/3 server entry paths:
  1. On the HTTP/1.1 path:

Relevant Code Locations

HTTP/2 metadata builder:

HTTP/3 metadata builder:

HTTP/2 server entry:

HTTP/3 server entry:

Shared HTTP compliance verification:

HTTP/1.1 authority/Host consistency check:

Defined but not enforced on H2/H3:

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:
    • Host = evil.example:
  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:

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

Tests Used

HTTP/2 rejection test:

HTTP/2 exploitability test:

HTTP/3 rejection test:

HTTP/3 exploitability test:

Observed behavior:

Project-Internal Evidence of Real Impact

Examples:

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:

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:

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

Disclosure Status

References

Related advisories

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Check my repo

Summarize with AI

ChatGPTClaudePerplexity

Sources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.