RUSTSEC-2026-0347: Buffered application data sent to outer server after ECH rejection

What to do

1. See which version you have: cargo tree -i rustls (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p rustls. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example rustls = "0.23.46") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

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'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.

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.

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 "before sending any application data to the server".

This affects only clients that:

• 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).

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.

References

• Package: crates.io/crates/rustls
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0347.html
• Web: github.com/rustls/rustls/pull/3300

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for rustls

• Vulnerability HighRUSTSEC-2024-0336 · 2024-04-19`rustls::ConnectionCommon::complete_io` could fall into an infinite loop based on network input
• VulnerabilityRUSTSEC-2024-0399 · 2024-11-22rustls network-reachable panic in `Acceptor::accept`
• Vulnerability MediumRUSTSEC-2026-0285 · 2026-09-14TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
• Vulnerability MediumRUSTSEC-2026-0346 · 2026-10-14`Debug` impls for client session values expose TLS secrets
• Vulnerability LowRUSTSEC-2026-0348 · 2026-10-14Brotli certificate decompression can allocate up to 1 GiB before authentication
• Vulnerability LowRUSTSEC-2026-0349 · 2026-10-14Unauthenticated ServerHello can downgrade later connections to classical key exchange

Full security history of rustls