https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 11 Nov 2026 00:05:43 +0000 https://db.gcve.eu/vuln/cve-2026-123612 <p><strong>Affected:</strong> 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> 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/cve-2026-123612 https://db.gcve.eu/vuln/ghsa-vp88-798v-h67f <p><strong>Affected:</strong> crates.io: rustls</p> <p>In rustls 0.23.44 and 0.23.45, application data that a client buffers before the handshake completes is sent to the server even when the server rejects Encrypted Client Hello (ECH).</p> <p>When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config&#39;s `public_name`. At the end of the handshake, `start_traffic()` encrypts and queues any plaintext buffered by `ClientConnection::writer()`. It does this *before* checking for `EchStatus::Rejected` and queueing the `ech_required` alert.</p> <p>The application then receives `Error::PeerIncompatible(ServerRejectedEncryptedClientHello)`, as expected. However, the client is still expected to call `write_tls()` to send the fatal alert, and that call also sends the encrypted application data. The server decrypts the data and only then receives the alert.</p> <p>The ordering bug is older than 0.23.44. Before 0.23.44, the client checked the server certificate against the inner server name rather than `public_name`, so a correctly configured server failed certificate verification first and no data was sent. 0.23.44 fixed that check, which makes the ordinary rejection path reachable.</p> <p># Impact</p> <p>Plaintext meant for the inner server, the one named in the encrypted ClientHello, goes to the client-facing server identified by `public_name`. That server is properly authenticated, so this is not an attack by an unauthenticated party. However this violates [RFC 9849](https://www.rfc-ed…</p> <p><strong>Affected:</strong> crates.io: rustls</p> <p>In rustls 0.23.44 and 0.23.45, application data that a client buffers before the handshake completes is sent to the server even when the server rejects Encrypted Client Hello (ECH).</p> <p>When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config&#39;s `public_name`. At the end of the handshake, `start_traffic()` encrypts and queues any plaintext buffered by `ClientConnection::writer()`. It does this *before* checking for `EchStatus::Rejected` and queueing the `ech_required` alert.</p> <p>The application then receives `Error::PeerIncompatible(ServerRejectedEncryptedClientHello)`, as expected. However, the client is still expected to call `write_tls()` to send the fatal alert, and that call also sends the encrypted application data. The server decrypts the data and only then receives the alert.</p> <p>The ordering bug is older than 0.23.44. Before 0.23.44, the client checked the server certificate against the inner server name rather than `public_name`, so a correctly configured server failed certificate verification first and no data was sent. 0.23.44 fixed that check, which makes the ordinary rejection path reachable.</p> <p># Impact</p> <p>Plaintext meant for the inner server, the one named in the encrypted ClientHello, goes to the client-facing server identified by `public_name`. That server is properly authenticated, so this is not an attack by an unauthenticated party. However this violates [RFC 9849](https://www.rfc-ed…</p> https://db.gcve.eu/vuln/ghsa-vp88-798v-h67f