CVE-2026-123613: 
Linux Debian 脆弱性分析と緩和策

CVE-2026-123613 is a TLS 1.3 handshake encryption level bypass vulnerability in the Rustls library, a modern TLS implementation written in Rust. The flaw causes Rustls to incorrectly accept TLS 1.3 handshake messages at the wrong encryption level when they follow a key-changing message within the same TLS record, because Deframer::aligned does not enforce RFC 8446 record-boundary alignment. This allows a peer or on-path attacker to pack a plaintext EncryptedExtensions message alongside a ServerHello, which Rustls accepts without proper encryption verification. Affected versions are Rustls 0.23.13 through 0.23.44 (inclusive); version 0.23.45 contains the fix. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Github Advisory).

The root cause is classified as CWE-20 (Improper Input Validation). Specifically, the Deframer::aligned function in Rustls considers itself aligned as long as all messages remaining in the buffer are complete, without verifying that messages do not span key-change boundaries as required by RFC 8446 Section 5.1. During a TLS 1.3 handshake, Rustls processes the ServerHello, installs the handshake keys, and then pulls a complete but plaintext EncryptedExtensions message from the same record buffer — accepting it without requiring it to be encrypted. The attack is network-based, requires no privileges or user interaction, and can be performed by any on-path or peer attacker. This issue is analogous to Go's CVE-2025-61730, and other major TLS implementations (Botan, OpenSSL, BoringSSL, Go, wolfSSL) correctly reject this protocol flow (GitHub Advisory).

Successful exploitation allows an on-path or peer attacker to inject plaintext handshake messages (specifically EncryptedExtensions) that Rustls accepts without encryption verification, potentially enabling the attacker to influence or observe TLS handshake parameters such as negotiated extensions. Importantly, the handshake transcript remains authenticated, so an attacker cannot use this flaw to alter or complete a handshake undetected, and cannot fully decrypt session traffic. The practical impact is limited to a partial confidentiality exposure (low) with no integrity or availability impact, but it represents a meaningful violation of the TLS 1.3 security model (GitHub Advisory, Github Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Github Advisory). The vulnerability was discovered using a new TLS/DTLS test suite under construction, inspired by the analogous Go CVE-2025-61730. The EPSS score is approximately 0.156%, indicating a low near-term exploitation probability. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Network Positioning: Attain an on-path (man-in-the-middle) or peer network position between a TLS client using a vulnerable Rustls version (0.23.13–0.23.44) and a TLS server.
2. Intercept TLS Handshake: Intercept the TLS 1.3 handshake at the point where the server sends its ServerHello message.
3. Craft Malicious Record: Construct a single TLS record that contains both the ServerHello message and a plaintext (unencrypted) EncryptedExtensions message packed into the same record, violating RFC 8446 record-boundary alignment requirements.
4. Inject the Record: Forward the crafted record to the Rustls client. Rustls processes the ServerHello, installs handshake keys, and then incorrectly accepts the plaintext EncryptedExtensions from the same buffer without requiring it to be encrypted.
5. Influence Handshake Parameters: The accepted plaintext EncryptedExtensions may allow the attacker to observe or influence negotiated TLS extension parameters without the connection being terminated (GitHub Advisory).

• Network: Anomalous TLS 1.3 handshake records where a ServerHello and EncryptedExtensions appear within the same TLS record (detectable via packet capture and TLS-aware inspection tools such as Wireshark).
• Logs: Unexpected or malformed TLS handshake sequences in application or TLS library debug logs; absence of expected unexpected_message alerts from the Rustls client when receiving improperly structured handshake records.
• Application Behavior: TLS connections completing successfully despite protocol violations that conformant implementations (OpenSSL, BoringSSL, Go) would reject with an alert.

The primary remediation is to upgrade Rustls to version 0.23.45 or later, which enforces proper RFC 8446 record-boundary alignment in Deframer::aligned. All applications embedding Rustls versions 0.23.13 through 0.23.44 should be updated immediately. No configuration-based workaround is available; patching is the only effective mitigation. Administrators should review TLS connection logs for anomalies during the vulnerability window if exposure is suspected (GitHub Advisory, Github Advisory).

The vulnerability was reported to the Rustls project by a researcher (randombit) who discovered it using a new TLS/DTLS test suite, noting its similarity to Go's CVE-2025-61730. The Rustls maintainer (ctz) published the advisory and patch promptly. The issue was noted to affect only Rustls among tested implementations, as Botan, OpenSSL, BoringSSL, Go, and wolfSSL all correctly reject the malformed protocol flow. Community discussion was observed on Mastodon/infosec.exchange and tracked by several vulnerability intelligence platforms (GitHub Advisory).