AI analysis
wolfSSL's TLS 1.2 and DTLS 1.2 client state machine wrongly accepts a ChangeCipherSpec record that arrives before the client has sent its ClientKeyExchange, at a point where no master secret has been derived yet. The client then installs read keys derived from a known, deterministic key and validates the server's Finished message against those same keys, so an attacker can inject an out-of-order ChangeCipherSpec to complete the handshake in place of the genuine server and deliver data the client accepts as authentic. The client's own traffic still uses correctly derived keys, so its confidentiality is not broken and the real server never completes the handshake, making this an integrity-only flaw rated CVSS 4.0 6.3 (medium). DTLS 1.2 client builds are exposed by default, while TLS 1.2 clients are only exposed when the application feeds received bytes through wolfSSL_inject() or enables read-ahead; certificate-based suites additionally require a man-in-the-middle position, but PSK-mode clients can be spoofed by any fake server that does not even know the pre-shared key. No public proof of concept is known and there is no indication of exploitation in the wild; the flaw is one of eleven TLS issues fixed in wolfSSL 5.9.4.
What to do: Upgrade to wolfSSL 5.9.4, and if you ship wolfSSL inside your product, pull in the patch and issue a fixed firmware release. If upgrading is not immediately possible, disable read-ahead and avoid wolfSSL_inject() in TLS 1.2 clients, and prefer TLS 1.3 where both endpoints support it; note that PSK-based DTLS 1.2 client connections cannot be reliably protected short of patching, so audit devices that initiate DTLS 1.2 sessions (e.g., CoAP-based IoT telemetry) as a priority.
Affected
| wolfSSL Inc. wolfSSL embedded SSL/TLS library (TLS 1.2 / DTLS 1.2 client code paths) | Prior to 5.9.4 (fixed in 5.9.4) |
Estimated exposure
large≈100k–1M+ devices (order of magnitude); exact count unknown — wolfSSL is a widely used embedded TLS library shipped inside IoT, networking, automotive, and industrial products, but no public census or internet-scan data identifies how many of those deployments run the affected configurations (DTLS…
Description
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 wolfSSL_inject() 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.