CVE-2026-89136 in wolfSSL
Summary
by MITRE • 09/27/2026
When using RPK (Raw Public Key), the client side of a TLS 1.2, 1.3 and DTLS 1.2 connection could accept an unsolicited server_cert_type=RawPublicKey which allowed a malicious or misbehaving server to bypass authentication. RPK is off by default and only enabled in --enable-rpk OR --enable-all OR --enable-distro AKA HAVE_RPK builds.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability described involves a critical flaw in the implementation of Raw Public Key (RPK) support within TLS 1.2, TLS 1.3, and DTLS 1.2 protocols during client-side authentication processes. In standard Transport Layer Security operations, mutual authentication or server authentication relies on the verification of digital certificates issued by trusted Certificate Authorities to establish trust chains. However, RPK is a mechanism that allows endpoints to authenticate each other using raw public keys without relying on traditional X.509 certificate infrastructure. The specific technical flaw lies in how the client handles unsolicited announcements from the server regarding its authentication type. Specifically, if a malicious or misbehaving server sends an unsolicited server_cert_type=RawPublicKey message, the vulnerable client implementation incorrectly accepts this assertion and proceeds with the handshake using RPK logic without proper validation of whether such a mode was explicitly negotiated or permitted by policy. This behavior effectively allows the attacker to bypass standard authentication checks because the client fails to enforce that RPK usage must be mutually agreed upon through explicit configuration rather than being coerced via unsolicited protocol messages.
This flaw has significant operational implications for security architectures relying on TLS and DTLS for secure communications, particularly in environments where automated or headless devices utilize RPK for lightweight authentication. By bypassing the expected certificate-based verification process, an attacker can perform man-in-the-middle attacks, impersonate legitimate servers, or intercept sensitive data without detection. The severity is compounded by the fact that this vulnerability affects multiple protocol versions including TLS 1.2 and 1.3 as well as DTLS 1.2, indicating a systemic issue in the shared codebase handling certificate type negotiations across these protocols. For organizations deploying IoT devices, industrial control systems, or other constrained environments where RPK is utilized to reduce computational overhead associated with certificate parsing and validation, this vulnerability represents a direct path to compromise integrity and confidentiality of communications.
From a classification perspective, this issue aligns closely with CWE-287 Improper Authentication, as the system fails to correctly verify the identity of the server before establishing trust. It also relates to CWE-693 Protection Mechanism Failure because the client does not properly enforce the intended security policy regarding authentication methods. In terms of MITRE ATT&CK framework mapping, this vulnerability facilitates techniques associated with T1078 Valid Accounts or more specifically impersonation tactics where an attacker leverages protocol misconfiguration to masquerade as a trusted entity. The lack of strict enforcement for negotiated parameters allows the adversary to manipulate the handshake state machine into accepting unverified public keys, thereby undermining the foundational trust model of TLS and DTLS.
Mitigation strategies must focus on both configuration management and software updates. Since RPK is disabled by default in most standard builds, organizations not explicitly using this feature are inherently protected against this specific vector unless they have enabled it via flags such as --enable-rpk, --enable-all, or distribution-specific configurations labeled HAVE_RPK. For those actively utilizing RPK, it is imperative to ensure that client implementations strictly validate that the server_cert_type=RawPublicKey was part of an explicit negotiation sequence rather than accepting unsolicited announcements. Administrators should review their deployment configurations to confirm whether RPK is enabled and assess if alternative authentication mechanisms like standard X.509 certificates are viable for their use case, thereby avoiding reliance on the more complex and error-prone raw key exchange entirely until a patched version of the library or protocol implementation is deployed. Patching involves updating to versions that enforce strict negotiation rules for certificate types, ensuring that unsolicited type changes cannot trigger authentication bypasses.