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

CVE-2026-123612 is an information disclosure vulnerability in the rustls TLS library affecting versions 0.23.44 and 0.23.45. When a server rejects an Encrypted Client Hello (ECH), application data buffered by the client before the handshake completes is incorrectly transmitted to the client-facing (public_name) server rather than being discarded. The vulnerability was published on November 8, 2026, with a patch available in version 0.23.46. It carries a CVSS v3.1 base score of 2.3 (Low) and a CVSS v4.0 base score of 4.6 (Medium) (Github Advisory, rustls Advisory).

The root cause is an incorrect behavior order (CWE-696) in rustls's ECH rejection handling. Specifically, the start_traffic() function encrypts and queues any plaintext buffered via ClientConnection::writer() before checking for EchStatus::Rejected and queuing the ech_required fatal alert. When the client subsequently calls write_tls() to send the alert, the encrypted application data is transmitted first, allowing the outer (public_name) server to decrypt and read it before receiving the alert. This ordering bug predates version 0.23.44, but was only made exploitable by a fix in that version that corrected certificate verification to check against public_name rather than the inner server name — making the ordinary ECH rejection path reachable without a prior certificate error. The vulnerability violates RFC 9849, which mandates that clients abort with an ech_required alert before sending any application data upon ECH rejection (rustls Advisory, Github Advisory).

Exploitation results in a confidentiality breach where plaintext application data intended for the inner (private) server is instead received and decrypted by the authenticated client-facing server identified by public_name. There is no integrity or availability impact. The scope is limited to clients using EchMode::Enable (not GREASE ECH) that write application data before the handshake completes and connect to a server that rejects their ECH config (e.g., due to a stale config). While the receiving server is properly authenticated — meaning this is not an unauthenticated interception — the data disclosure violates the privacy guarantees that ECH is designed to provide (rustls Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is approximately 0.11%, placing it in the 1st percentile for exploitation likelihood. Exploitation requires high privileges on the local system and is constrained to a specific combination of conditions: ECH enabled, application data written pre-handshake, and a server returning ECH rejection with retry configs. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

The Rustls project has released version 0.23.46 which fixes the incorrect behavior order by ensuring the ech_required alert is queued before any buffered application data is transmitted. Organizations using rustls 0.23.44 or 0.23.45 should upgrade to 0.23.46 or later as the primary remediation. As a temporary workaround, applications can avoid writing data to ClientConnection::writer() before the TLS handshake completes when using EchMode::Enable (rustls Advisory, Github Advisory).

The vulnerability was disclosed by the rustls maintainers via a GitHub Security Advisory (GHSA-vp88-798v-h67f) and was also covered by VulnCheck in a dedicated advisory. Community discussion was noted on Infosec.Exchange, and the issue was indexed by multiple vulnerability tracking platforms including OSV, VulnDB, and INCIBE-CERT shortly after disclosure (rustls Advisory).