CVE-2026-93304: (D)TLS 1.2 client accepts early ChangeCipherSpec before ClientKeyExchange

Published Sep 27, 2026
·
Updated

A (D)TLS 1.2 client can accept a ChangeCipherSpec message before it has sent its ClientKeyExchange. No master secret has been derived at that point, so the client installs read keys derived from a known (deterministic) key and checks the server's Finished against that same key. An out-of-order ChangeCipherSpec can therefore be used by an attacker to complete the handshake in place of the server and send data the client accepts as authentic. The client's own traffic still uses correctly derived keys, so the attacker cannot read it, and the genuine server never completes the handshake. DTLS 1.2 clients are exposed because a datagram read can deliver the out-of-order records on its own. TLS 1.2 clients are exposed when the application supplies received bytes with wolfSSLinject() or enables read ahead. For certificate suites, the attacker must be in a man-in-the-middle position. For PSK (Pre Shared Key) connections, any fake server can succeed without knowing the PSK.

Affected Software

1 affected component
wolfSSL wolfssl

Event History

Sep 27, 2026
CVE Published
via MITRE·09:05 AM
Data Sourced
via MITRE·09:05 AM
DescriptionWeakness
Data Sourced
via NVD·10:16 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which client deployments are exposed?

DTLS 1.2 clients are exposed because datagram delivery can present the out-of-order records independently. TLS 1.2 clients are exposed only when the application feeds received bytes through wolfSSL_inject() or has read ahead enabled.

2

What attacker position is required?

For certificate-based cipher suites, the attacker must be positioned as a man in the middle. For PSK connections, a fake server can complete the attack without knowing the PSK.

3

Can the attacker read data sent by the client?

No. The client continues to use correctly derived keys for its own outbound traffic, so the attacker cannot read that traffic; the genuine server also never completes the handshake.

4

What does successful exploitation allow the attacker to do?

The attacker can complete the handshake while impersonating the server and send data that the client accepts as authentic.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203