AI analysis
wolfSSL clients built with Raw Public Key (RPK) support can accept an unsolicited server_cert_type=RawPublicKey during TLS 1.2, TLS 1.3, or DTLS 1.2, which lets a malicious or misbehaving server skip authentication (CWE-287). The issue is triggered on the client side of an RPK-capable handshake; RPK is off by default and is present only in builds configured with --enable-rpk, --enable-all, or --enable-distro (HAVE_RPK). A successful bypass can undermine server authentication and expose the client to an unauthenticated peer, with high integrity impact and limited confidentiality impact (CVSS 4.0 8.3). Only deployments that actually enable RPK are affected; ordinary default builds are not. It is not on the CISA KEV list, and no public proof-of-concept is known.
What to do: If you do not need Raw Public Key, rebuild wolfSSL without --enable-rpk, --enable-all, or --enable-distro (HAVE_RPK). Where RPK is required, apply the vendor fix as soon as it is published and confirm clients reject an unsolicited server_cert_type=RawPublicKey. No fixed version is named in this advisory data.
Affected
| wolfSSL | Client builds with RPK enabled (--enable-rpk, --enable-all, or --enable-distro / HAVE_RPK) for TLS 1.2, TLS 1.3, and DTLS 1.2; RPK is off by default. No version |
Estimated exposure
—No basis for an estimate.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.