Summary
rustls: ECH rejection can expose buffered application data to authenticated outer server before ech_required alert
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.
Impact
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:
- Section 6.1.6: if the handshake and authentication succeed after ECH rejection, the client "MUST ... abort the connection with an "ech_required" alert before sending any application data to the server."
- Section 6.1.7: the certificate is checked only against
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:
- They use
EchMode::Enable. GREASE ECH is not affected. - They write application data before the handshake completes.
- They connect to a server that rejects their ECH config, for example because the config is stale. This is the same case where the server returns retry configs.
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.
GHSA-VP88-798V-H67F has a CVSS score of 2.3 (Low). The vector is requires local access, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.23.46, 0.24.0-dev.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
rustls to 0.23.46 or later; rustls to 0.24.0-dev.2 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-VP88-798V-H67F? GHSA-VP88-798V-H67F is a low-severity security vulnerability in rustls (rust), affecting versions >= 0.23.44, < 0.23.46. It is fixed in 0.23.46, 0.24.0-dev.2.
- How severe is GHSA-VP88-798V-H67F? GHSA-VP88-798V-H67F has a CVSS score of 2.3 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of rustls are affected by GHSA-VP88-798V-H67F? rustls (rust) versions >= 0.23.44, < 0.23.46 is affected.
- Is there a fix for GHSA-VP88-798V-H67F? Yes. GHSA-VP88-798V-H67F is fixed in 0.23.46, 0.24.0-dev.2. Upgrade to this version or later.
- Is GHSA-VP88-798V-H67F exploitable, and should I be worried? Whether GHSA-VP88-798V-H67F is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-VP88-798V-H67F is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-VP88-798V-H67F?
- Upgrade
rustlsto 0.23.46 or later - Upgrade
rustlsto 0.24.0-dev.2 or later
- Upgrade