CVE-2026-55962: TLS 1.3 Post-Handshake Authentication Bypass in wolfSSL

Technical summary

CVE-2026-55962 is an authentication bypass in wolfSSL's TLS 1.3 post-handshake authentication (PHA) implementation. The vulnerability stems from a scope misalignment in the certificate verification logic. Specifically, an exemption allowing empty or absent peer certificates—intended only for the initial handshake—was incorrectly applied during post-handshake CertificateRequest exchanges. Once a server sends a post-handshake CertificateRequest (setting certReqCtx), the peer must provide both a Certificate message and a valid CertificateVerify before the Finished message is accepted. The fix narrows this exemption to apply only during initial handshake, ensuring post-handshake authentication requests enforce full certificate validation according to the configured FAIL_IF_NO_PEER_CERT policy. The issue is isolated to TLS 1.3 and requires explicit use of WOLFSSL_VERIFY_POST_HANDSHAKE and the wolfSSL_request_certificate() API.

Business impact

For organizations deploying wolfSSL with TLS 1.3 post-handshake authentication—a pattern used in scenarios requiring mutual re-authentication or deferred client authentication—this vulnerability breaks the authentication model. An attacker with network access and an established TLS session could potentially bypass the post-handshake client authentication check, gaining unauthorized access to protected resources or operations that should require fresh client proof-of-possession. This is most critical in zero-trust architectures or APIs using continuous authentication. Organizations not explicitly enabling post-handshake authentication are not affected.

Affected systems

Only wolfSSL deployments are affected. Specifically: servers running wolfSSL with TLS 1.3 support, compiled with post-handshake authentication enabled (--enable-postauth or --enable-all), that enable the WOLFSSL_VERIFY_POST_HANDSHAKE configuration flag and actively invoke wolfSSL_request_certificate() to demand client authentication after handshake completion. Client applications using wolfSSL are not vulnerable, nor are servers that do not use the post-handshake authentication feature. Other TLS libraries are unaffected.

Exploitability

Exploitation requires network-level access to initiate or maintain a TLS connection to the vulnerable server, as well as knowledge that post-handshake authentication is in use (Low privilege barrier). An attacker cannot exploit this remotely without an established session. The CVSS 3.1 score of 6.5 (MEDIUM) reflects low attack complexity and no user interaction needed, but requires existing authentication context. The integrity impact is high because the authentication control is bypassed, but confidentiality and availability are not directly affected. This is not listed in CISA's Known Exploited Vulnerabilities catalog.

Remediation

Apply the patched version of wolfSSL when available. Verify the vendor advisory for the specific patched release addressing this certificate validation scope fix. Interim mitigation: organizations should audit production deployments to confirm whether WOLFSSL_VERIFY_POST_HANDSHAKE is actually enabled and whether post-handshake certificate requests are in active use; many deployments may not use this feature. If post-handshake authentication is not required for your security model, disabling or not compiling in this feature eliminates the risk entirely.

Patch guidance

Monitor the wolfSSL project (https://www.wolfssl.com/) for security advisories and patched releases. Verify against the vendor advisory which version addresses this CVE and update accordingly. Given the narrow scope (post-handshake auth only), patching should be straightforward with no breaking changes for applications not using that feature. Test any update in a staging environment to confirm compatibility.

Detection guidance

Monitor wolfSSL library versions in use and cross-reference against patched releases when announced. Review application configuration and source code to identify any use of WOLFSSL_VERIFY_POST_HANDSHAKE or wolfSSL_request_certificate(). Network-based detection is difficult because the flaw is in authentication logic, not payload parsing; focus on application-level logging of post-handshake authentication events and ensure they are properly enforced. Consider adding explicit auditing around certificate acceptance during post-handshake phases.

Why prioritize this

This is a MEDIUM-severity authentication bypass with a low privilege barrier and network accessibility. While exploitation requires an active session, the vulnerability directly undermines an authentication control, which is typically a critical security function. Organizations using post-handshake authentication should prioritize patching, as this is a targeted flaw in a specific advanced feature rather than a widespread default-configuration issue. Those not using the feature can deprioritize below critical vulnerabilities affecting base functionality.

Risk score, explained

CVSS 3.1 score of 6.5 reflects: (1) Network attack surface (AV:N), (2) Low attack complexity—no special conditions required (AC:L), (3) Low privilege requirement (PR:L, suggesting an established connection), (4) No user interaction (UI:N), (5) High integrity impact (I:H) because authentication is bypassed, (6) No confidentiality or availability impact (C:N/A:N). The score appropriately captures a focused authentication bypass with limited scope (post-handshake TLS 1.3 only), not a widespread vulnerability in the core library.

Frequently asked questions