CVE-2026-123613 · Package
NO FIX YET · SEE WHAT TO DO
Rustls accepts TLS 1.3 handshake messages at the wrong encryption level when they follow a key-changing message in the same record, because record-boundary alignment is not enforced. A peer or on-path attacker can place a plaintext EncryptedExtensions message alongside the ServerHello, and rustls accepts it unencrypted.
first public Sep 14, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Applications built on rustls 0.23.13 through 0.23.45 that accept TLS 1.3 connections. The attacker must be a peer or sit on the network path between client and server. Services that do not use rustls, or that run a version outside this range, are not affected.
Not affected if no-rustls-usage, version-outside-range
Who cares cargo, rust, rustls, tls
rustls version in Cargo.lock or cargo tree output for each service.0.23.13 up to but not including 0.23.45.rustls 0.23.45 (fixed version for the 0.23.x line, per the affected range 0.23.13 to before 0.23.45)Rustls from 0.23.13 before 0.23.45 accepts TLS 1.3 handshake messages at the wrong encryption level when they follow a key-changing message in the same record, because Deframer::aligned does not enforce RFC 8446 record-boundary alignment. A peer or on-path attacker can pack a plaintext EncryptedExtensions with the ServerHello, which rustls accepts unencrypted.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.