rustls 0.23.46: Four Advisories, and Which Ones Apply to You

On 14 October 2026 rustls 0.23.46 was published to crates.io, and RustSec issued four advisories against earlier versions the same day. One month earlier, 0.23.45 fixed a fifth issue. All are rated low or medium, and most need a particular feature, API or deployment to matter. Since rustls sits underneath a large share of Rust networking code, it's worth knowing which ones reach your build.

None of the five has a CVE ID. They are tracked as RUSTSEC and GHSA identifiers.

What's affected

Upgrade target: rustls 0.23.46 or later.

RUSTSEC-2026-0349 (GHSA-w44r-93j7-qv28), key exchange downgrade, CVSS 3.7. The client recorded which key exchange group the server chose while processing the ServerHello, before the server was authenticated, and used that record to predict key shares on later connections to the same name. A network attacker can answer one connection with a ServerHello choosing X25519 and drop it. Later ClientHellos then send only an X25519 share. If the real server accepts it rather than asking for its preferred hybrid group with a HelloRetryRequest, the connection completes with classical key exchange instead of X25519MLKEM768. The impact is loss of post-quantum protection, not key compromise. Clients with resumption disabled are not affected.

RUSTSEC-2026-0346 (GHSA-c8m5-c952-6cm4), secrets in Debug output, CVSS 4.0. Debug for Tls12ClientSessionValue and Tls13ClientSessionValue was derived, so it printed the TLS 1.2 master secret or the TLS 1.3 resumption PSK. Only applications with a custom ClientSessionStore that format these values, for example in logs, are affected. Versions before 0.21.0 are not.

RUSTSEC-2026-0348 (GHSA-h2v8-394m-p7vv), Brotli allocation, CVSS 3.7. With the non-default brotli feature, a five-byte header could make certificate decompression allocate 1 GiB before authentication. Clients connecting to a malicious server, and servers that request client certificates, are affected if the feature is on. Versions before 0.23.9 are not.

RUSTSEC-2026-0347 (GHSA-vp88-798v-h67f), data sent after ECH rejection, CVSS 2.3. When a server rejected Encrypted Client Hello, rustls sent any application data buffered before the handshake finished to the outer public_name server. It needs EchMode::Enable (GREASE is fine), early writes, and a rejected ECH config. Only 0.23.44 and 0.23.45 are affected.

RUSTSEC-2026-0285 (GHSA-2mjx-qc3c-rqvc), September, CVSS 5.3. rustls accepted TLS 1.3 handshake messages at the wrong encryption level when they followed a key-changing message in the same record. The transcript is still authenticated, so an attacker can't alter a handshake. Versions 0.23.13 up to 0.23.45 are affected; 0.23.45 fixed it on 14 September.

How to check if you're exposed

Find which rustls versions your lockfile resolves, and through which crates:

cargo tree -i rustls --edges normal
grep -A1 'name = "rustls"' Cargo.lock

Check whether the Brotli feature is turned on anywhere in the graph:

cargo tree -i rustls -e features | grep -i brotli

Search your own code for the APIs the narrower advisories need:

# RUSTSEC-2026-0346: custom session stores
grep -rn "impl.*ClientSessionStore" --include=*.rs .

# RUSTSEC-2026-0347: ECH enabled (not GREASE)
grep -rn "EchMode::Enable" --include=*.rs .

And run the advisory database against the lockfile:

cargo install cargo-audit --locked
cargo audit

What to do now

1. Update rustls to 0.23.46:

   cargo update -p rustls
   

   If several rustls versions are in the tree, cargo update -p rustls@0.23.45 targets one. A direct dependency pinned below 0.23.46 in Cargo.toml needs its requirement raised first.
2. Rebuild and redeploy. Like any crate fix, it only takes effect in new binaries.
3. If you implement ClientSessionStore, search logs and error reports for Tls12ClientSessionValue or Tls13ClientSessionValue output. If they were logged, treat the resumption secrets as exposed and purge those logs.
4. If you rely on post-quantum key exchange, check your server side too. The downgrade only works against servers that accept the predicted share instead of sending a HelloRetryRequest for their preferred group.
5. If you enabled brotli only for certificate compression, weigh whether you need it. Fewer optional features means fewer advisories that apply.

Why it matters

These advisories are a good example of why severity scores alone make poor triage. A CVSS 5.3 issue that the transcript still protects, and a CVSS 2.3 issue that needs three conditions, sit next to a CVSS 3.7 issue that quietly undoes the post-quantum protection a team may have adopted on purpose. The right order depends on which features and APIs you use.

They are also a reminder that a TLS library's attack surface grows with its features. ECH, certificate compression and key share prediction each arrived to make TLS faster or more private, and each brought new state to get right.

Try it yourself

Run cargo tree -i rustls -e features on one service and write down every rustls feature that's enabled and which crate enabled it. Then match each of the five advisories to that list: applies, doesn't apply, or needs a code search. That is reachability triage done by hand.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RUSTSEC-2026-0349: Unauthenticated ServerHello can downgrade later connections
• RUSTSEC-2026-0346: Debug impls for client session values expose TLS secrets
• RUSTSEC-2026-0348: Brotli certificate decompression can allocate up to 1 GiB
• RUSTSEC-2026-0347: Buffered application data sent to outer server after ECH rejection
• RUSTSEC-2026-0285: TLS 1.3 handshake messages accepted across encryption levels
• rustls versions on crates.io