CVE-2026-42505

What it actually does

The flaw allows a passive network observer to correlate or de-anonymize TLS handshakes that are intended to be protected by Encrypted Client Hello. Although ECH is designed to hide sensitive ClientHello metadata such as the true destination name, affected handshakes may expose pre-shared key identities in the unencrypted outer ClientHello. This can reveal enough stable identifying information for an observer to link sessions, infer the hidden service being accessed, or reduce the privacy guarantees of ECH. The issue does not provide code execution, authentication bypass, traffic decryption, data modification, or service disruption by itself.

Why it matters to the business

Organizations relying on Encrypted Client Hello for privacy may unintentionally disclose metadata about user browsing, service access, or application destinations to network observers such as ISPs, enterprise proxies, hostile Wi-Fi operators, or nation-state monitoring infrastructure. The likely impact is privacy loss, user tracking, and exposure of sensitive access patterns rather than direct system compromise. The current exploitation signal is low: EPSS is approximately 0.00382, unchanged over 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated. However, because exploitation can be passive and leave little to no trace, organizations with strong privacy, regulatory, journalistic, legal, healthcare, or high-risk-user requirements should treat remediation as more important than the score alone suggests.

How an attack unfolds

An attacker positions themselves where they can observe network traffic, such as on the same network path, at an ISP, in a compromised routing position, on a monitored Wi-Fi network, or at a network tap. The attacker passively records TLS ClientHello messages from clients using Encrypted Client Hello. In vulnerable implementations or configurations, the outer, unencrypted ClientHello includes pre-shared key identities. The attacker extracts those identities and uses them to correlate repeated connections, distinguish users or applications, or infer the protected destination that ECH was meant to hide. No interaction with the client or server is required beyond observing traffic, and exploitation may not generate any endpoint logs or visible application errors.

How to fix it

Upgrade affected TLS libraries, browsers, clients, servers, proxies, or ECH-enabled components to vendor-fixed versions when available. No affected product or fixed-version list was provided, so security teams should consult the relevant vendor advisories for all software that implements TLS 1.3 session resumption, pre-shared keys, and Encrypted Client Hello. Where immediate patching is not available, consider disabling ECH session resumption or PSK use for ECH connections if the vendor supports such a control, or temporarily disabling ECH where metadata privacy degradation is unacceptable and the implementation cannot be corrected. Avoid custom TLS/ECH implementations unless they have been reviewed for correct separation of sensitive values between the encrypted inner ClientHello and unencrypted outer ClientHello. Ensure edge proxies, TLS inspection devices, client stacks, and server-side TLS terminators are all reviewed, because the issue may arise in any component constructing or processing ECH handshakes.

How to confirm the fix worked

Confirm remediation by checking vendor package versions against the relevant fixed releases once published. Perform packet-capture validation from a controlled client and server using ECH and TLS 1.3 resumption. Inspect the outer ClientHello and verify that PSK identities or stable resumption identifiers that reveal the protected destination are not present in cleartext. Use tools such as Wireshark, tshark, Zeek, or vendor TLS debug logging to confirm that ECH is still functioning while sensitive ClientHello content is confined to the encrypted inner ClientHello. Regression-test both first connections and resumed connections, because the exposure concerns pre-shared key identities and may only appear during resumption flows.

Typical attack path

1. Gain passive visibility into client-to-server network traffic, for example through a network tap, ISP-level observation, hostile wireless network, proxy, or compromised routing path.
2. Capture TLS ClientHello messages from clients that advertise or use Encrypted Client Hello.
3. Inspect the unencrypted outer ClientHello for exposed pre-shared key identity values.
4. Correlate exposed PSK identities across sessions, clients, destinations, or time periods.
5. Use correlation results to infer hidden service names, user activity patterns, or relationships that ECH was intended to protect.

How to detect it

This issue is difficult to detect after the fact because exploitation can be completely passive: an observer only needs to record network traffic and may never touch the client, server, or application. There may be no authentication logs, process artifacts, file changes, alerts, or application errors. To assess whether exposure occurred, review any retained packet captures, Zeek logs, TLS metadata logs, proxy telemetry, or network sensor records that include TLS ClientHello extension details. Look for TLS 1.3 ClientHello messages that contain both Encrypted Client Hello-related extensions and pre_shared_key identities in the unencrypted outer ClientHello. If full packet capture is available, inspect resumed ECH handshakes and compare whether PSK identity values are visible before ECH decryption. Treat matches primarily as evidence of exposure, not proof that an adversary collected the traffic. For suspected targeted monitoring, correlate exposure windows with known network vantage points, hostile Wi-Fi usage, unusual routing changes, ISP or upstream packet-loss events, lawful intercept concerns, or prior evidence of network taps. Because no known KEV listing, ransomware use, named threat actor, or mature exploit is reported, detection should focus on passive metadata exposure rather than malware-style indicators.

• encrypted_client_hello
• pre_shared_key
• psk_key_exchange_modes
• ech_outer_extensions
• TLS ClientHello extension encrypted_client_hello
• TLS ClientHello extension pre_shared_key
• extension_type: encrypted_client_hello
• extension_type: pre_shared_key

What your security team should do

• Inventory products and services that support or terminate Encrypted Client Hello, TLS 1.3 pre-shared keys, and session resumption, including browsers, mobile apps, TLS libraries, proxies, CDN integrations, and server-side TLS terminators.
• Track vendor advisories and apply fixed versions as soon as available for all affected ECH-capable components.
• Prioritize remediation for environments where metadata privacy is a security requirement, such as sensitive user populations, regulated communications, high-risk research, legal services, healthcare, journalism, or anti-censorship use cases.
• Use packet captures to test whether ECH handshakes expose PSK identities in the outer ClientHello before and after remediation.
• If patching is delayed, evaluate disabling ECH PSK/session resumption or ECH itself where the privacy risk outweighs the performance or privacy benefits of the current implementation.
• Do not rely on compromise detection alone; passive exploitation may leave no host-side artifacts and may only be visible if network traffic was already captured.