CVE-2026-89136: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-89136 is an authentication bypass vulnerability in wolfSSL affecting the Raw Public Key (RPK) implementation in TLS 1.2, TLS 1.3, and DTLS 1.2 connections. When RPK is enabled, the client side of a connection could accept an unsolicited server_cert_type=RawPublicKey extension from the server, allowing a malicious or misbehaving server to bypass authentication. Affected versions span wolfSSL 5.6.0 through 5.9.2 (inclusive). The vulnerability was disclosed on September 27, 2026, with a patch merged on August 11, 2026. It carries a CVSS v4.0 base score of 8.3 (High) (GitHub Advisory, wolfSSL PR #11009).

The root cause is classified as CWE-287 (Improper Authentication): wolfSSL's client-side TLS handshake processing failed to enforce "offered vs. received" constraints for the server_cert_type extension defined in RFC 7250 and RFC 8446. Specifically, the client did not verify that it had previously advertised support for RawPublicKey before accepting a server_cert_type=RawPublicKey response from the server, allowing an unsolicited negotiation to succeed. The fix, contributed by Christos Papakonstantinou of Cantina Security and implemented in src/tls.c, enforces that only cert-type values explicitly offered by the client during the handshake are accepted. This vulnerability is only present in builds compiled with --enable-rpk, --enable-all, or --enable-distro flags (i.e., HAVE_RPK builds); RPK is off by default (wolfSSL PR #11009, GitHub Advisory).

Successful exploitation enables a malicious or adversary-in-the-middle server to bypass server authentication in TLS/DTLS sessions, meaning the client cannot verify the server's true identity. This primarily impacts integrity (CVSS v4 Vulnerable System Integrity: High) and to a lesser extent confidentiality (Low), as an attacker who impersonates a legitimate server could intercept or manipulate data exchanged during the session. Availability is not directly impacted. The attack scope is limited to systems using wolfSSL compiled with RPK support, but within that scope, any TLS 1.2, TLS 1.3, or DTLS 1.2 client connection is at risk of man-in-the-middle interception (GitHub Advisory, wolfSSL PR #11009).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.0055 (0.55%), indicating a low near-term probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to be in a network position to intercept or control TLS handshake traffic (Attack Requirements: Present), limiting opportunistic exploitation, though no privileges or user interaction are required once that position is achieved.

1. Identify target: Locate a client application using wolfSSL compiled with --enable-rpk, --enable-all, or --enable-distro (i.e., HAVE_RPK defined), running versions 5.6.0 through 5.9.2.
2. Establish network position: Position the attacker as an adversary-in-the-middle between the wolfSSL client and its intended server (e.g., via ARP spoofing, DNS poisoning, or rogue access point on a local network).
3. Intercept TLS handshake: Capture the client's TLS ClientHello. The client may or may not include a client_cert_type extension advertising RPK support.
4. Inject unsolicited RPK extension: Respond to the client with a crafted ServerHello that includes server_cert_type=RawPublicKey even if the client did not request it. Due to the vulnerability, the unpatched wolfSSL client accepts this unsolicited extension.
5. Bypass server authentication: Present an arbitrary raw public key instead of a valid certificate chain. The client, having accepted the unsolicited RPK negotiation, does not perform standard certificate-based server authentication.
6. Conduct man-in-the-middle attack: With server authentication bypassed, relay or manipulate traffic between the client and the real server, intercepting sensitive data or injecting malicious content (wolfSSL PR #11009, GitHub Advisory).

• Network: Unexpected server_cert_type=RawPublicKey extension in TLS ServerHello messages on connections where the client did not advertise RPK support in its ClientHello; TLS handshakes completing with a raw public key credential rather than an X.509 certificate chain.
• Logs: TLS handshake logs showing successful session establishment with cert_type=RawPublicKey on clients not configured to use RPK; anomalous certificate type negotiation entries in application-level TLS debug logs.
• Network: Unusual intermediate hosts or unexpected IP addresses appearing in network flows between wolfSSL clients and known servers, potentially indicating an adversary-in-the-middle position.

Upgrade wolfSSL to a version beyond 5.9.2 that includes the fix merged in pull request #11009 (merged August 11, 2026). If RPK functionality is not required, recompile wolfSSL without the --enable-rpk, --enable-all, or --enable-distro build flags to eliminate the HAVE_RPK code path entirely and remove the attack surface. Organizations unable to upgrade immediately should audit their build configurations to confirm RPK is not inadvertently enabled via --enable-all or --enable-distro (wolfSSL PR #11009, GitHub Advisory).

The vulnerability was reported by Christos Papakonstantinou of Cantina Security, who also reported several other issues addressed in the same pull request (wolfSSL PR #11009). No significant broader media coverage or notable public researcher commentary beyond the GitHub advisory and pull request discussion has been identified at this time.