CVE-2026-3230: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-3230 is a missing cryptographic step vulnerability in wolfSSL's TLS 1.3 client HelloRetryRequest handshake logic that can lead to confidentiality compromise of TLS-protected communications. It affects all wolfSSL versions prior to 5.9.0. The flaw was disclosed on March 19, 2026, with a patch merged on February 10, 2026 and publicly tracked from March 20, 2026. It carries a CVSS v3.1 base score of 2.7 (Low) and a CVSS v4.0 base score of 1.2 (Low) (Red Hat Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-325 (Missing Cryptographic Step) and CWE-20 (Improper Input Validation). During a TLS 1.3 handshake, when a server sends a crafted HelloRetryRequest followed by a ServerHello message that omits the required key_share extension, wolfSSL's client fails to enforce the presence of this extension before proceeding. This causes the client to derive traffic secrets from a predictable (EC)DHE shared secret rather than a properly negotiated one, weakening the confidentiality guarantees of the session. The fix, merged in GitHub pull request #9754, adds an explicit check for the KeyShare extension in the ServerHello message (wolfSSL PR #9754, Red Hat Bugzilla).

Successful exploitation could allow an attacker with high privileges and network access to derive predictable TLS 1.3 traffic secrets, potentially enabling decryption of encrypted communications between a wolfSSL client and a server. The impact is limited to confidentiality — integrity and availability are not affected, and server authentication during the TLS handshake remains intact. The vulnerability's scope is constrained to the TLS session in which the crafted handshake occurs, limiting lateral movement potential (Red Hat Advisory, Red Hat Bugzilla).

1. Positioning: Attain a man-in-the-middle (MitM) network position between a wolfSSL TLS 1.3 client (running a version prior to 5.9.0) and a legitimate TLS server, for example via ARP spoofing, DNS hijacking, or rogue access point.
2. Intercept ClientHello: Capture the initial TLS 1.3 ClientHello message sent by the wolfSSL client, which includes a key_share extension with the client's ephemeral public key.
3. Craft HelloRetryRequest: Forge and send a crafted HelloRetryRequest (HRR) message to the client, prompting it to restart the handshake and generate a new key share.
4. Send malformed ServerHello: After the client sends a second ClientHello, respond with a ServerHello message that omits the required key_share extension, exploiting the missing validation in wolfSSL's HRR handling logic.
5. Derive predictable secrets: Because wolfSSL does not enforce the presence of the key_share extension in the ServerHello after an HRR, the client proceeds to derive traffic secrets from a predictable or attacker-influenced (EC)DHE shared secret.
6. Decrypt traffic: Use knowledge of the predictable shared secret to derive session keys and decrypt the TLS-protected communications between the client and server (wolfSSL PR #9754, Red Hat Bugzilla).

• Network: Unexpected or duplicate TLS 1.3 HelloRetryRequest messages observed in network captures between a wolfSSL client and server; ServerHello messages lacking a key_share extension following an HRR sequence.
• Network: Anomalous TLS handshake patterns where a ClientHello is sent twice in rapid succession without a corresponding legitimate server-side retry trigger.
• Logs: TLS handshake logs on the client side showing completion of a session after receiving a ServerHello without a key_share extension (detectable with verbose TLS debug logging enabled in wolfSSL).
• Process/Application: wolfSSL-linked applications running versions prior to 5.9.0 that handle sensitive encrypted communications and are exposed to untrusted network paths.

The primary remediation is to upgrade wolfSSL to version 5.9.0 or later, which includes the fix that adds an explicit check for the key_share extension in the ServerHello message following a HelloRetryRequest. The patch was merged on February 10, 2026 (PR #9754) and publicly released with version 5.9.0. No configuration-based workaround is available; upgrading is the only effective mitigation. Organizations using wolfSSL in embedded or IoT environments should prioritize updating given the library's widespread use in TLS-sensitive applications (wolfSSL PR #9754, Red Hat Bugzilla).

Red Hat tracked the vulnerability as low severity in their Bugzilla system, consistent with the low CVSS scores assigned. The wolfSSL development team responded quickly, with the fix merged within one day of the internal report (February 9–10, 2026) and a community member (GSoJC234) acknowledging the rapid resolution on GitHub. No significant broader media coverage or notable researcher commentary beyond standard CVE tracking has been identified (wolfSSL PR #9754, Red Hat Bugzilla).