https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 11:10:15 +0000 https://vulnerability.circl.lu/vuln/ghsa-7p3p-8qv8-m2vh <p><strong>Affected:</strong> Maven: org.eclipse.jetty:jetty-server</p> <p>#### Summary</p> <p>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:</p> <p>- logic based on `HttpURI` / `Request.getServerName(request)` uses `:authority` - logic based on raw request headers continues to use `Host`</p> <p>This creates a host/authority confusion condition that can break security assumptions in higher layers.</p> <p>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.</p> <p>#### Security Impact</p> <p>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:</p> <p>- 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</p> <p>Potential consequences include:</p> <p>- 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</p> <p>#### Technical Root Cause</p> <p>1. On the HTTP/2 and HTTP/3 metadata builder paths:</p> <p>- `:authority` is parsed separately into authority/URI state - `Host` is…</p> <p><strong>Affected:</strong> Maven: org.eclipse.jetty:jetty-server</p> <p>#### Summary</p> <p>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:</p> <p>- logic based on `HttpURI` / `Request.getServerName(request)` uses `:authority` - logic based on raw request headers continues to use `Host`</p> <p>This creates a host/authority confusion condition that can break security assumptions in higher layers.</p> <p>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.</p> <p>#### Security Impact</p> <p>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:</p> <p>- 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</p> <p>Potential consequences include:</p> <p>- 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</p> <p>#### Technical Root Cause</p> <p>1. On the HTTP/2 and HTTP/3 metadata builder paths:</p> <p>- `:authority` is parsed separately into authority/URI state - `Host` is…</p> https://vulnerability.circl.lu/vuln/ghsa-7p3p-8qv8-m2vh