Most recent entries from all

certfr-2026-avi-1094 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan…

certfr-2026-avi-1094

Withdrawn: CLEANSTART-2026-AB17721 — Security fixes in solr 10.0.0-r6

Withdrawn by the publisher.

Affected: CleanStart: solr

Package solr version 10.0.0-r6 fixes 4 vulnerabilities: CVE-2026-8384, CVE-2026-6790, CVE-2026-10051, CVE-2026-10050

EUVD-2026-336259

fkie_cve-2026-6790

In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present).

This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112).

This mismatch can cause a number of problems that may be classified as vulnerabilities such as:

* URI constructions (for example, for redirects -- this is typical for login pages)

* Virtual host selection

* Reverse proxying

* Misleading logs

* Etc.

Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.

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

Affected: Maven: org.eclipse.jetty:jetty-server

#### 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…

UBUNTU-CVE-2026-6790

Affected: Ubuntu:16.04:LTS: jetty9, Ubuntu:18.04:LTS: jetty9, Ubuntu:20.04:LTS: jetty9, Ubuntu:22.04:LTS: jetty9, Ubuntu:24.04:LTS: jetty9, Ubuntu:26.04:LTS: jetty12, Ubuntu:26.04:LTS: jetty9

In Eclipse Jetty, for HTTP/1, HTTP/2 and HTTP/3 requests, there is no strict check that the request authority (host and port) matches what provided in the Host header (if present). This was not enforced in earlier HTTP RFC (for example, in RFC 2616), but it is in the latest RFC (9110 and 9112). This mismatch can cause a number of problems that may be classified as vulnerabilities such as: * URI constructions (for example, for redirects -- this is typical for login pages) * Virtual host selection * Reverse proxying * Misleading logs * Etc. Given that the latest RFCs require that request authority and Host header must match, Jetty should enforce this invariant.

WID-SEC-W-2026-2314 — Eclipse Jetty: Mehrere Schwachstellen

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Eclipse Jetty ausnutzen, um einen Denial of Service Angriff durchzuführen, Sicherheitsmaßnahmen zu umgehen und vertrauliche Informationen offenzulegen.