https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 22:20:20 +0000 https://cve.radiocsirt.org/vuln/cve-2026-10051 <p><strong>Affected:</strong> Eclipse Foundation Eclipse Jetty</p> <p>In Eclipse Jetty, a first HTTP/1.1 request with trailers causes the server to retain the trailers in subsequent requests performed over the same connection. Subsequent request that do not have trailers report the trailers of the first request. Subsequent request that do have trailers report the union of trailers of the first request and the current request.</p> <p><strong>Affected:</strong> Eclipse Foundation Eclipse Jetty</p> <p>In Eclipse Jetty, a first HTTP/1.1 request with trailers causes the server to retain the trailers in subsequent requests performed over the same connection. Subsequent request that do not have trailers report the trailers of the first request. Subsequent request that do have trailers report the union of trailers of the first request and the current request.</p> https://cve.radiocsirt.org/vuln/cve-2026-10051 https://cve.radiocsirt.org/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://cve.radiocsirt.org/vuln/ghsa-7p3p-8qv8-m2vh