CVE-2026-89136: TLS/DTLS RPK Authentication Bypass Vulnerability

CVE-2026-89136 Overview

CVE-2026-89136 is an authentication bypass vulnerability in wolfSSL affecting the client side of TLS 1.2, TLS 1.3, and DTLS 1.2 connections when Raw Public Key (RPK) support is compiled in. The client accepts an unsolicited server_cert_type=RawPublicKey extension from the server, allowing a malicious or misbehaving server to bypass certificate-based authentication. The flaw is categorized under [CWE-287: Improper Authentication]. RPK is disabled by default and requires builds configured with --enable-rpk, --enable-all, or --enable-distro (HAVE_RPK).

Critical Impact
A hostile TLS or DTLS server can authenticate to vulnerable wolfSSL clients using a Raw Public Key the client never negotiated, defeating peer authentication and enabling impersonation or man-in-the-middle attacks on affected connections.

Affected Products

wolfSSL builds compiled with HAVE_RPK (--enable-rpk)
wolfSSL builds compiled with --enable-all
wolfSSL distribution builds compiled with --enable-distro

Discovery Timeline

2026-09-27 - CVE-2026-89136 published to NVD
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-89136

Vulnerability Analysis

The vulnerability resides in the wolfSSL client's handling of the RFC 7250 Raw Public Key certificate type negotiation. During the TLS handshake, a client and server negotiate the acceptable certificate types using the client_certificate_type and server_certificate_type extensions. A compliant client must only accept a server_certificate_type value that it explicitly offered.

In affected wolfSSL builds, the client does not verify that the server_cert_type=RawPublicKey response corresponds to an extension it actually sent. A server can therefore unilaterally select RPK, causing the client to parse and trust a bare SubjectPublicKeyInfo structure in place of an X.509 certificate chain. This bypasses the normal certificate validation path, including chain building and trust-anchor checks.

Because RPK authentication relies on an out-of-band mapping of public keys to identities, forcing a client into RPK mode without a configured trust mapping breaks peer authentication entirely for the affected session.

Root Cause

The root cause is missing input validation on the negotiated server_certificate_type extension in the client state machine. The client fails to confirm that RawPublicKey was present in its own offered list before accepting it from the server.

Attack Vector

An attacker operating a malicious TLS 1.2, TLS 1.3, or DTLS 1.2 server, or an active network attacker able to redirect a victim client to such a server, responds to the handshake with server_cert_type=RawPublicKey regardless of what the client negotiated. The client then validates against the attacker-supplied raw public key, resulting in a bypass of certificate authentication. See the upstream fix in the wolfSSL GitHub Pull Request #11009 for implementation details.

Detection Methods for CVE-2026-89136

Indicators of Compromise

TLS or DTLS handshakes where the server returns a server_certificate_type extension containing RawPublicKey without the client having offered RPK in its ClientHello.
Unexpected SubjectPublicKeyInfo structures delivered in place of X.509 Certificate messages to clients that normally expect X.509 chains.
Outbound connections from applications linked against wolfSSL HAVE_RPK builds to untrusted or newly observed destinations.

Detection Strategies

Inventory binaries and packages linked against wolfSSL and identify those built with --enable-rpk, --enable-all, or --enable-distro.
Inspect TLS handshake telemetry for mismatches between offered and accepted certificate-type extensions.
Alert on wolfSSL client processes initiating sessions that complete without an X.509 certificate validation event.

Monitoring Recommendations

Capture full TLS handshake metadata, including extension values, in network sensors that terminate or passively observe TLS.
Monitor application logs from wolfSSL-based services for RPK negotiation events and correlate them against expected trust configurations.
Track outbound connections from embedded and IoT devices known to ship wolfSSL distro builds.

How to Mitigate CVE-2026-89136

Immediate Actions Required

Identify all deployments using wolfSSL builds with HAVE_RPK enabled and prioritize them for patching.
Upgrade wolfSSL to the fixed release containing the changes from wolfSSL Pull Request #11009.
Where upgrades cannot be deployed immediately, rebuild wolfSSL without --enable-rpk, --enable-all, or --enable-distro if RPK is not required.

Patch Information

The fix is tracked in wolfSSL Pull Request #11009, which enforces that the client only accepts a server_certificate_type value it previously offered. Downstream distributions should pull the corresponding release of wolfSSL and rebuild dependent packages.

Workarounds

Disable RPK support at build time by omitting --enable-rpk, --enable-all, and --enable-distro configure flags.
Restrict wolfSSL clients to connect only to servers under administrative control until patched versions are deployed.
Enforce network egress controls so that wolfSSL-based clients cannot reach untrusted TLS or DTLS endpoints.

bash

# Rebuild wolfSSL without Raw Public Key support
./configure --disable-rpk
make
sudo make install