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:54:04 +0000 https://db.gcve.eu/vuln/cleanstart-2026-gs73039 <p><strong>Affected:</strong> CleanStart: rustup</p> <p>Security vulnerability affects the rustup package. This issue is resolved in later releases. See references for vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: rustup</p> <p>Security vulnerability affects the rustup package. This issue is resolved in later releases. See references for vulnerability details.</p> https://db.gcve.eu/vuln/cleanstart-2026-gs73039 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