CVE-2026-93304: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-93304 is an authentication bypass vulnerability in wolfSSL's (D)TLS 1.2 implementation caused by incorrect handshake message ordering. A (D)TLS 1.2 client incorrectly accepts a ChangeCipherSpec (CCS) message before sending its ClientKeyExchange (CKE), causing it to install read keys derived from a known deterministic key rather than a properly negotiated master secret. This allows an attacker to impersonate the server and inject data the client accepts as authentic. Affected versions span wolfSSL 4.7.0 through 5.9.2. The vulnerability was disclosed on September 27, 2026, with a patch merged on September 18, 2026, and carries a CVSS v4.0 base score of 6.3 (Medium) (Github Advisory, wolfSSL PR).

The root cause is CWE-696 (Incorrect Behavior Order): wolfSSL's TLS 1.2 state machine fails to enforce that a ChangeCipherSpec message must only be processed after the ClientKeyExchange has been sent. Because no master secret exists at that point, the client derives read keys from a known, deterministic value and validates the server's Finished message against that same predictable key — effectively making the handshake verification trivially bypassable. DTLS 1.2 clients are inherently exposed because a single datagram read can deliver out-of-order records; TLS 1.2 clients are exposed only when the application uses wolfSSL_inject() or enables read-ahead mode. For certificate-based cipher suites, a man-in-the-middle position is required, but for PSK connections any attacker can succeed without knowing the PSK or holding a privileged network position. The fix, merged in PR #11458, enforces that CCS processing is forbidden until after CKE is sent (wolfSSL PR, Github Advisory).

Successful exploitation allows an attacker to complete the TLS/DTLS handshake in place of the legitimate server, enabling injection of arbitrary data that the client accepts as authentic server responses. The client's outbound traffic remains encrypted with correctly derived keys, so the attacker cannot decrypt it, but the genuine server never completes the handshake, effectively denying the client a legitimate connection. The primary impact is an integrity breach — the client may act on attacker-controlled data believing it originated from a trusted server — with particular risk in IoT, embedded, and industrial environments where wolfSSL is commonly deployed (Github Advisory, wolfSSL PR).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of disclosure (Github Advisory). The EPSS score is approximately 0.194%, indicating a low near-term exploitation probability. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation complexity is rated High for certificate-based suites (requiring a MITM position), but notably lower for PSK connections where any network-accessible attacker can succeed without knowing the pre-shared key.

1. Identify target: Locate a DTLS 1.2 client using wolfSSL 4.7.0–5.9.2, or a TLS 1.2 client using wolfSSL with wolfSSL_inject() or read-ahead enabled. DTLS targets (e.g., embedded IoT devices, VPN clients) are the most accessible attack surface.
2. Position for interception: For certificate-based suites, establish a man-in-the-middle position between the client and server (e.g., via ARP spoofing, DNS poisoning, or rogue access point). For PSK-based connections, simply operate a fake server — no MITM position is required.
3. Intercept the ClientHello: Allow or forge the initial ClientHello from the victim client to proceed normally, establishing the beginning of the handshake.
4. Send premature ChangeCipherSpec: Before the client sends its ClientKeyExchange, inject a ChangeCipherSpec record to the client. Due to the vulnerability, the client accepts this out-of-order message.
5. Forge the Finished message: Because the client derives its read keys from a known deterministic value (no master secret exists yet), compute the expected Finished message using that same predictable key and send it to the client.
6. Inject malicious data: With the handshake accepted by the client, send arbitrary application-layer data that the client processes as legitimate server responses, potentially manipulating application logic, credentials, or commands (Github Advisory, wolfSSL PR).

• Network: DTLS or TLS sessions where a ChangeCipherSpec record is observed in the network capture before the ClientKeyExchange message from the client; unexpected session terminations where the legitimate server never completes the handshake.
• Network: For PSK deployments, connections completing handshakes with unrecognized or unexpected server endpoints.
• Logs: Application logs showing successful TLS/DTLS session establishment followed immediately by unexpected server-side behavior or connection resets from the legitimate server.
• Process/Application: wolfSSL-linked applications receiving and processing data from sessions where the handshake sequence was anomalous; unexpected application behavior or command execution triggered by injected server responses.

The primary remediation is to upgrade wolfSSL to a version beyond 5.9.2; the fix was merged into the master branch on September 18, 2026, and is targeted for release version 5.9.4 (wolfSSL PR). If immediate patching is not possible, organizations should disable wolfSSL_inject() and the read-ahead feature in TLS 1.2 applications to eliminate the TLS exposure vector (DTLS 1.2 clients remain exposed regardless of these settings). PSK-based deployments should be treated as highest priority since exploitation does not require a man-in-the-middle position. The vulnerability was reported by Anthropic and credited accordingly in the patch.

The vulnerability was reported to wolfSSL by Anthropic, as credited in the pull request description (wolfSSL PR). The fix was reviewed and approved by wolfSSL maintainer JacobBarthelmeh and passed automated security scanning by wolfSSL's Fenrir bot with no new issues found. No significant broader media coverage or notable public researcher commentary beyond the GitHub advisory and patch discussion has been observed at this time.