Repository navigation
RUSTSEC-2026-0285: TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries #3222
Description
TLS 1.3 handshake messages incorrectly accepted across encryption level boundaries
| Details | |
|---|---|
| Package | rustls |
| Version | 0.23.41 |
| URL | GHSA-2mjx-qc3c-rqvc |
| Date | 2026-09-14 |
| Patched versions | >=0.23.45 |
| Unaffected versions | <0.23.13 |
Rustls accepted TLS 1.3 handshake messages sent at the wrong encryption level
when they followed a key-changing message in the same record. For example,
a plaintext EncryptedExtensions message packed into the same record as the
ServerHello was accepted.
RFC 8446 section 5.1 requires that handshake messages do not span key changes,
and that implementations terminate the connection with an "unexpected_message"
alert if they do.
The handshake transcript is still authenticated, so a network-position attacker
cannot use this to alter or complete a handshake; the practical effect is that
a peer could send handshake messages that should be encrypted in plaintext
without rustls rejecting the connection.
This is functionally the same bug as Go's
GO-2026-4340 (CVE-2025-61730).
See advisory page for additional details.
Activity
dannycjones commentedon Sep 15, 2026
Took a quick look at this in the context of the 0.11.0 RC2 vote (#3034) (which I've not yet sent out, just doing validations myself).
0.11.0RC2'sCargo.lockspecifies 0.23.41 impacted by this issue, however this should not be relevant for published crates as the lock file is relevant for binary targets. Running a quickcargo updateshows it resolving to 0.23.45. If anyone's downstream workspace targets an affectedrustlsversion, tooling should flag it and it is resolved by performing acargo update. Updating the Cargo lock file for the release would not help in any way.I think this does not impact 0.11.0 release candidate 2. Please let me know if you think otherwise.
chore(deps): bump rustls to 0.23.45 (RUSTSEC-2026-0285)