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

CVE-2026-123611 is a key exchange downgrade vulnerability in the rustls TLS library (written in Rust) that allows unauthenticated network attackers to poison a client's per-server-name key-exchange group record via a crafted ServerHello message. Affected versions are all rustls releases before 0.23.46. The vulnerability was published on November 8, 2026, with the corresponding security advisory (GHSA-w44r-93j7-qv28) published by the rustls project on October 14, 2026. It carries a CVSS v3.1 base score of 3.7 (Low) and a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory, GitHub Advisory DB).

The root cause is classified as CWE-757 (Selection of Less-Secure Algorithm During Negotiation / Algorithm Downgrade). In TLS 1.3, rustls records the server-selected key-exchange group per server name when it processes the ServerHello — critically, before the server has been authenticated. An on-path or network attacker can intercept one connection attempt for a target server name, respond with a spoofed ServerHello selecting the classical X25519 group, and then close the connection; no certificate or completed handshake is required. Subsequent ClientHellos from the victim client for that server name will include only a classical X25519 key share (while supported_groups still lists X25519MLKEM768 first), and if the legitimate server accepts that share rather than issuing a HelloRetryRequest, the handshake completes with classical key exchange only — silently stripping post-quantum confidentiality with no error raised. TLS 1.3 transcript binding prevents editing a ClientHello mid-connection but does not prevent pre-poisoning the client's prediction state from an unauthenticated message (GitHub Advisory).

The primary impact is a loss of post-quantum confidentiality for TLS connections between clients and the targeted server name, exposing encrypted traffic to "harvest now, decrypt later" attacks by a future quantum adversary. There is no key compromise, no authentication bypass, and no integrity or availability impact — the handshake completes normally and no error is surfaced to the application. The effect persists for as long as the poisoned entry remains in the client's key-exchange group store, potentially affecting all subsequent connections to that server name from the same client (GitHub Advisory, GitHub Advisory DB).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.188% (9th percentile), indicating a low near-term exploitation probability (GitHub Advisory DB). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a network attacker capable of intercepting or answering a connection attempt (man-in-the-middle or network-adjacent position), raising the attack complexity.

1. Positioning: Attain a network position capable of intercepting or answering TLS connection attempts from the target rustls client to a specific server name (e.g., via ARP spoofing, BGP hijacking, or a rogue network node).
2. Intercept connection attempt: Wait for or trigger the victim client to initiate a TLS 1.3 handshake to the target server name. The client's ClientHello will advertise X25519MLKEM768 as the preferred key-exchange group.
3. Send spoofed ServerHello: Respond to the ClientHello with a crafted ServerHello that selects the classical X25519 group. No certificate or completed handshake is required — simply send the ServerHello and close the connection.
4. Poison the client's state: The rustls client records X25519 as the server-preferred group for that server name in its per-name key-exchange store, before any server authentication occurs.
5. Observe downgraded future connections: On subsequent connection attempts by the same client to the same server name, the ClientHello will carry only a classical X25519 key share. If the legitimate server accepts this share (rather than sending a HelloRetryRequest), the handshake completes with classical key exchange only.
6. Harvest encrypted traffic: Capture the now-classically-encrypted TLS sessions for future decryption by a quantum adversary, exploiting the eliminated post-quantum confidentiality (GitHub Advisory).

• Network: Unexpected or anomalous TLS ServerHello messages for a known server name that select X25519 instead of the expected hybrid group (X25519MLKEM768), followed immediately by connection closure without completing the handshake.
• Network: ClientHello messages from a rustls client that advertise X25519MLKEM768 in supported_groups but include only a classical X25519 key share in the key_share extension for a server name that should support hybrid key exchange.
• Logs: TLS handshake logs showing repeated classical-only key exchange completions (X25519) for a server that is configured to prefer or support X25519MLKEM768, with no HelloRetryRequest observed.
• Behavioral: A pattern of short-lived, incomplete TLS connections to a target server name (attacker probing/poisoning) preceding a shift in the client's key share selection for that name (GitHub Advisory).

Upgrade rustls to version 0.23.46 or later (also fixed in >= 0.24.0-dev.2), which corrects the handling of the per-server-name key-exchange group record to prevent unauthenticated ServerHello messages from poisoning client state (GitHub Advisory). As a configuration-based workaround, disabling TLS session resumption on the client prevents the vulnerable state from being stored. Additionally, servers can be configured to always send a HelloRetryRequest when a ClientHello does not include a hybrid key share, which forces the connection to remain hybrid at the cost of one extra round trip. Organizations prioritizing post-quantum confidentiality should treat this patch as high priority.

The vulnerability was reported by researcher Adam010341 and disclosed responsibly through the rustls project's security advisory process (GitHub Advisory). The advisory notes that the underlying behavior is discussed in the IETF draft draft-ietf-tls-key-share-prediction, indicating awareness of this class of issue in the standards community. Community and media reaction has been limited given the low CVSS v3.1 score and absence of active exploitation, though the vulnerability is notable for its relevance to post-quantum cryptography migration efforts.