rustls EUVD-2026-119372

Exploitation requires that the attacker be the connecting TLS 1.3 peer (e.g. a malicious server) or sit on-path, and that the target run rustls 0.23.13-0.23.44 processing a TLS 1.3 handshake; the attacker packs a key-changing message (ServerHello) and a following handshake message (EncryptedExtensions) into a single record so the trailing message crosses the key-change boundary in plaintext. No authentication, user interaction, or special configuration is needed (PR:N/UI:N), and default TLS 1.3 handshaking is affected. The decisive LIMITING factor is that the handshake transcript is still cryptographically authenticated, so the attacker cannot alter or complete a handshake, forge a peer, or downgrade the connection - impact is confined to rustls failing to reject plaintext handshake messages that should have been encrypted, which is why confidentiality impact is only Low and integrity/availability are None.

This is a genuine but moderate-severity TLS protocol-conformance flaw, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with only VC:L and no integrity or availability impact correctly reflects a low-consequence issue: rustls (0.23.13-0.23.44) fails to enforce RFC 8446 §5.1 record-boundary alignment in Deframer::aligned, so a peer or on-path attacker can pack a plaintext EncryptedExtensions into the same record as the ServerHello and have rustls accept it unencrypted. Crucially, the vendor advisory states the handshake transcript remains authenticated, so a network-position attacker cannot alter or complete a handshake or downgrade security - the practical effect is limited to accepting handshake messages that should have been encrypted, consistent with the VC:L / VI:N / VA:N rating. No EPSS score, KEV listing, or confirmed working exploit code is present in the input; exploitation status is therefore 'no public exploit identified at time of analysis,' though a detailed root-cause report and a directly analogous Go bug (CVE-2025-61730) exist. The vuln.today Decision label is 'this_month' (not act_now/emergency), aligning with the moderate CVSS and absence of active-exploitation signals. Bottom line: a real correctness bug worth patching on a normal cadence, not a drop-everything priority.

A malicious or on-path TLS server sends a TLS 1.3 server flight in which a plaintext EncryptedExtensions message is packed into the same record immediately following the ServerHello. A vulnerable rustls peer installs the handshake keys after the ServerHello but still pulls the trailing plaintext EncryptedExtensions from the buffer and accepts it, rather than terminating with an 'unexpected_message' alert as RFC 8446 requires. No public working exploit code is identified, but a detailed report describing the exact protocol flow exists and the issue was confirmed by a conformance test suite.