https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 10 Nov 2026 23:53:35 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-123612 <p>rustls 0.23.44 and 0.23.45 contain an information disclosure vulnerability that sends application data buffered before the handshake completes to the client-facing server when Encrypted Client Hello is rejected. Because start_traffic() queues plaintext from ClientConnection::writer() before sending the ech_required alert, the authenticated public_name server receives data intended for the inner server.</p> <p>rustls 0.23.44 and 0.23.45 contain an information disclosure vulnerability that sends application data buffered before the handshake completes to the client-facing server when Encrypted Client Hello is rejected. Because start_traffic() queues plaintext from ClientConnection::writer() before sending the ech_required alert, the authenticated public_name server receives data intended for the inner server.</p> https://db.gcve.eu/vuln/fkie_cve-2026-123612 https://db.gcve.eu/vuln/ghsa-jrx3-hh25-gg3m <p>rustls 0.23.44 and 0.23.45 contain an information disclosure vulnerability that sends application data buffered before the handshake completes to the client-facing server when Encrypted Client Hello is rejected. Because start_traffic() queues plaintext from ClientConnection::writer() before sending the ech_required alert, the authenticated public_name server receives data intended for the inner server.</p> <p>rustls 0.23.44 and 0.23.45 contain an information disclosure vulnerability that sends application data buffered before the handshake completes to the client-facing server when Encrypted Client Hello is rejected. Because start_traffic() queues plaintext from ClientConnection::writer() before sending the ech_required alert, the authenticated public_name server receives data intended for the inner server.</p> https://db.gcve.eu/vuln/ghsa-jrx3-hh25-gg3m https://db.gcve.eu/vuln/rustsec-2026-0347 <p><strong>Affected:</strong> crates.io: rustls</p> <p>When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config&#39;s `public_name`. At the end of that handshake, rustls encrypted and queued any application data buffered via `ClientConnection::writer()` *before* queueing the `ech_required` alert.</p> <p>The application correctly receives `Error::PeerIncompatible(ServerRejectedEncryptedClientHello)`, but the next `write_tls()` call (needed to send the alert) also sends the buffered application data. Plaintext meant for the inner server therefore goes to the client-facing server named by `public_name`.</p> <p>That server is authenticated, so this is not exploitable by an unauthenticated party, but it violates RFC 9849 section 6.1.6, which requires the client to abort with `ech_required` &#34;before sending any application data to the server&#34;.</p> <p>This affects only clients that:</p> <p>- use `EchMode::Enable` (GREASE ECH is not affected), - write application data before the handshake completes, and - connect to a server that rejects their ECH config (for example, because it is stale).</p> <p>The underlying ordering bug is older, but before 0.23.44 the client checked the server certificate against the inner server name rather than `public_name`, so certificate verification failed first and no data was sent.</p> <p><strong>Affected:</strong> crates.io: rustls</p> <p>When a server rejects Encrypted Client Hello (ECH), the client completes the handshake using the outer ClientHello and authenticates the server against the ECH config&#39;s `public_name`. At the end of that handshake, rustls encrypted and queued any application data buffered via `ClientConnection::writer()` *before* queueing the `ech_required` alert.</p> <p>The application correctly receives `Error::PeerIncompatible(ServerRejectedEncryptedClientHello)`, but the next `write_tls()` call (needed to send the alert) also sends the buffered application data. Plaintext meant for the inner server therefore goes to the client-facing server named by `public_name`.</p> <p>That server is authenticated, so this is not exploitable by an unauthenticated party, but it violates RFC 9849 section 6.1.6, which requires the client to abort with `ech_required` &#34;before sending any application data to the server&#34;.</p> <p>This affects only clients that:</p> <p>- use `EchMode::Enable` (GREASE ECH is not affected), - write application data before the handshake completes, and - connect to a server that rejects their ECH config (for example, because it is stale).</p> <p>The underlying ordering bug is older, but before 0.23.44 the client checked the server certificate against the inner server name rather than `public_name`, so certificate verification failed first and no data was sent.</p> https://db.gcve.eu/vuln/rustsec-2026-0347 https://db.gcve.eu/vuln/ubuntu-cve-2026-123612 <p><strong>Affected:</strong> Ubuntu:24.04:LTS: rust-rustls, Ubuntu:26.10: rust-rustls, Ubuntu:26.04:LTS: rust-rustls</p> <p>rustls 0.23.44 and 0.23.45 contain an information disclosure vulnerability that sends application data buffered before the handshake completes to the client-facing server when Encrypted Client Hello is rejected. Because start_traffic() queues plaintext from ClientConnection::writer() before sending the ech_required alert, the authenticated public_name server receives data intended for the inner server.</p> <p><strong>Affected:</strong> Ubuntu:24.04:LTS: rust-rustls, Ubuntu:26.10: rust-rustls, Ubuntu:26.04:LTS: rust-rustls</p> <p>rustls 0.23.44 and 0.23.45 contain an information disclosure vulnerability that sends application data buffered before the handshake completes to the client-facing server when Encrypted Client Hello is rejected. Because start_traffic() queues plaintext from ClientConnection::writer() before sending the ech_required alert, the authenticated public_name server receives data intended for the inner server.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-123612