CVE-2026-55960: wolfSSL Raw Public Key Bypass – Certificate Validation Vulnerability

Technical summary

The vulnerability stems from improper certificate type negotiation in wolfSSL's TLS implementation. During TLS handshake, the server and client should negotiate which certificate format to use: X.509 certificates (standard) or Raw Public Keys (RFC 7250). The function ParseCertRelative() was accepting raw public keys without verifying that RPK negotiation had actually occurred. An attacker could send a raw public key during a connection where X.509 was the negotiated (or default) type, and the parser would accept it without performing chain validation—which raw public keys inherently lack. The fix implements strict type checking: when no certificate type was explicitly negotiated, the implementation now defaults to X.509 per RFC 7250 and RFC 8446 specifications, and rejects any mismatch—including unexpected raw public keys—with an UNSUPPORTED_CERTIFICATE alert.

Business impact

This vulnerability allows attackers to bypass TLS mutual authentication controls, potentially enabling man-in-the-middle attacks, credential spoofing, or unauthorized access to systems relying on wolfSSL for secure communications. Organizations using wolfSSL in IoT devices, embedded systems, or constrained environments may be particularly exposed if they compiled with RPK support enabled. The impact depends on threat model: in scenarios where certificate validation is critical (financial services, critical infrastructure), this could lead to unauthorized transaction approval or system compromise. In other deployments, the risk is lower if network-level controls or application-layer authentication provide defense-in-depth.

Affected systems

Any wolfSSL installation compiled with Raw Public Key support enabled (HAVE_RPK flag set) is affected. This includes systems built with the --enable-all configuration flag. The vulnerability does not affect standard wolfSSL builds, which have RPK support disabled by default. End users and organizations should verify their wolfSSL compilation flags by checking build configuration or contacting their vendor/supplier if wolfSSL is bundled in a third-party product.

Exploitability

This vulnerability has a network attack vector with low complexity and no authentication or user interaction required, making it exploitable by a remote unauthenticated attacker. However, exploitation is practical only in environments where: (1) wolfSSL is compiled with RPK support, (2) the attacker can perform network-level interception or DNS/BGP manipulation, and (3) the application does not implement additional certificate pinning or validation outside the TLS stack. Public exploit code is not known to exist at this time, and the vulnerability is not tracked in CISA's Known Exploited Vulnerabilities catalog.

Remediation

Organizations using wolfSSL must apply the patch that implements certificate type validation as described in the vulnerability details. For most users operating standard wolfSSL builds, no immediate action is required since RPK support is disabled by default. However, organizations should: (1) inventory builds to identify any compiled with HAVE_RPK enabled, (2) prioritize patching those builds, and (3) review whether raw public key support is actually necessary for their use cases—disabling it at compile time further reduces attack surface.

Patch guidance

Apply the security update from wolfSSL that adds certificate type negotiation validation. Users should verify the patch version against the official wolfSSL advisory or release notes, as specific version numbers should be confirmed directly from the vendor. After patching, recompile any embedded or statically-linked instances of wolfSSL in your products. If RPK support is not required for your application, consider disabling the HAVE_RPK flag at compile time to eliminate the vulnerability class entirely. Test patched versions in a staging environment before production rollout, particularly in systems where certificate-based authentication is security-critical.

Detection guidance

Monitor for TLS handshake anomalies: log UNSUPPORTED_CERTIFICATE alerts (alert code 43) which would indicate the patch is active and rejecting invalid certificate types. In unpatched systems, look for raw public keys being accepted in connections where X.509 was negotiated—this may appear in certificate logging or detailed TLS debugging. Network-level detection is difficult without TLS interception; consider enabling verbose logging in wolfSSL (if operationally acceptable) during high-risk transactions. Most importantly, verify that your wolfSSL binaries were built without RPK support via build artifact inspection or configuration review.

Why prioritize this

While the CVSS score is 7.5 (HIGH), real-world risk depends heavily on deployment context. Prioritize patching if you: (1) compiled wolfSSL with --enable-all or explicitly enabled HAVE_RPK, (2) operate in security-sensitive verticals (finance, healthcare, critical infrastructure), or (3) face advanced persistent threat actors. Lower priority for standard builds or development/testing environments. The lack of KEV inclusion and public exploits suggests this is not yet actively exploited in the wild, providing a window for measured patching.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects high integrity impact (attacker can spoof authentication) over a network with no prerequisites, but the scope is unchanged (only TLS authentication affected, not system-wide). The actual operational risk is lower than the base score suggests because: exploitation requires RPK compilation flag to be set (most distributions disable it), the patch is straightforward, and there is no known public exploitation. Security leaders should weight this as a moderate-priority vulnerability to patch within standard update cycles, not an emergency—unless operating unpatched RPK-enabled builds in high-trust environments.

Frequently asked questions