CVE-2026-2645: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-2645 is a TLS 1.2 state machine logic flaw in wolfSSL that allows an attacker to submit handshake messages out of order, specifically accepting a CertificateVerify message before the ClientKeyExchange message has been received. This violates the required TLS handshake sequence and can enable authentication bypass. The vulnerability affects wolfSSL versions 5.8.2 and earlier; version 5.8.4 detects the issue later in the handshake, and version 5.9.0 includes further hardening to catch it earlier. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 5.5 (Medium) (Feedly, GitHub PR #9694).

The root cause is classified as CWE-358 (Improperly Implemented Security Check for Standard) — the TLS 1.2 server state machine in wolfSSL failed to enforce the correct ordering of handshake messages. Specifically, the server could accept a CertificateVerify message without first receiving the ClientKeyExchange message, violating RFC 5246's required handshake sequence. An unauthenticated remote attacker can exploit this by sending crafted, out-of-order TLS handshake messages to a vulnerable wolfSSL server, potentially forging authentication without possessing the client's private key. The fix, merged January 21, 2026 via GitHub pull request #9694, adds additional sanity checks on message ordering for TLS 1.2 and below (GitHub PR #9694, Feedly).

Successful exploitation allows an attacker to bypass TLS client authentication, potentially gaining unauthorized access to systems that rely on mutual TLS (mTLS) for identity verification. The primary impact is to integrity — an attacker can forge authentication credentials without possessing the legitimate client's private key. There is no direct confidentiality or availability impact, but unauthorized access enabled by this bypass could facilitate further lateral movement or data exfiltration depending on the protected resource (Feedly).

1. Reconnaissance: Identify network-accessible services running wolfSSL versions 5.8.2 or earlier that require TLS client certificate authentication (mTLS), using tools such as Nmap with TLS fingerprinting or Shodan.
2. Initiate TLS handshake: Begin a standard TLS 1.2 handshake with the target server, sending ClientHello and receiving ServerHello, Certificate, CertificateRequest, and ServerHelloDone.
3. Send out-of-order messages: Instead of following the correct sequence (sending ClientKeyExchange before CertificateVerify), send a crafted CertificateVerify message to the server before sending ClientKeyExchange, exploiting the state machine's failure to enforce message ordering.
4. Bypass authentication: The vulnerable server incorrectly accepts the CertificateVerify without having processed ClientKeyExchange, allowing the attacker to complete the handshake without possessing the legitimate client private key.
5. Gain unauthorized access: With the handshake accepted, the attacker establishes an authenticated TLS session and accesses resources protected by client certificate authentication (GitHub PR #9694, Feedly).

• Network: TLS handshake traffic where CertificateVerify messages appear before ClientKeyExchange in the message sequence; anomalous TLS session establishments from clients without valid certificates on mTLS-protected endpoints.
• Logs: TLS library or application logs showing unexpected handshake message ordering or state machine transitions; successful TLS sessions from clients that should not have valid certificates.
• Process/Application: Unexpected authenticated sessions on services using wolfSSL for mutual TLS, particularly from unknown or untrusted source IPs.

Upgrade wolfSSL to version 5.8.4 or later, which detects the out-of-order message issue during the handshake. Version 5.9.0 provides further hardening by catching the issue earlier in the handshake process. No configuration-based workaround is available; patching is the only effective remediation. Prioritize systems exposed to untrusted networks that use wolfSSL for mutual TLS authentication (GitHub PR #9694, Feedly).