Live › vulnerability › GHSA-vp88-798v-h67f
Go to dashboardWhen a server rejects Encrypted Client Hello, rustls 0.23.44 and 0.23.45 still send application data the client buffered before the handshake finished, to the outer server named by public_name. That server is authenticated, so an attacker does not gain access, but plaintext meant for the inner server reaches the wrong party.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 16:10 UTC. All times on this page are UTC.
Only clients that enable ECH with , write application data before the handshake completes, and connect to a server that rejects their ECH config, for example because it is stale. GREASE ECH is not affected, and servers are not directly exposed by this flaw. Teams that do not use ECH can skip it.
EchMode::Enable| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| rustls | cargo | >= 0.23.44, < 0.23.46 | 0.23.46 |
| rustls | cargo | >= 0.24.0-dev.1, < 0.24.0-dev.2 | 0.24.0-dev.2 |
cargo tree -i rustls and look for rustls at 0.23.44 or 0.23.45, or 0.24.0-dev.1.EchMode::Enable and for code that writes to the connection before the handshake completes.rustls to 0.23.46 or later on the 0.23 line.rustls to 0.24.0-dev.2 or later if you use the 0.24 development line.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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).
When the server rejects ECH, the client completes the handshake with the outer ClientHello and authenticates the server against the ECH config'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.
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.
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.
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, which says the following:
public_name, and the connection "MUST NOT" be reported as successful to the application. rustls does report failure correctly. The problem is only that data is sent before the alert.This affects only clients that meet all of these conditions:
EchMode::Enable. GREASE ECH is not affected.The usual client response to rejection is to retry with the server's retry configs. In that case, the data has already gone to the outer server.
This page as .md · .json · in your agent: get_signal("GHSA-vp88-798v-h67f")
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.