EUVD-2026-39575
GHSA-gq94-hf88-g4wv
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N for TLS network reachability; AC:H for non-default compile flags and explicit API calls required; PR:N as any client can open a TLS session; I:H for full authentication bypass.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
2DescriptionCVE.org
TLS 1.3 post-handshake authentication (PHA) issue where a server could accept a client's Finished message without the client having sent a Certificate and CertificateVerify. The post-handshake-auth exemption that allows an empty/absent peer certificate was only intended for the initial handshake, but it was also being applied while a post-handshake CertificateRequest was still outstanding. The check is now scoped to the initial handshake only: on the server, once a post-handshake CertificateRequest has been sent (certReqCtx is set), a peer certificate and a valid CertificateVerify are required again before the Finished is accepted, with empty-certificate handling following the configured verify mode (FAIL_IF_NO_PEER_CERT) just as during first-handshake client authentication. Only affects TLS 1.3 servers built with post-handshake authentication support (WOLFSSL_POST_HANDSHAKE_AUTH / --enable-postauth, included in --enable-all) that enable WOLFSSL_VERIFY_POST_HANDSHAKE and request a client certificate after the handshake via wolfSSL_request_certificate(). Clients, and servers that do not use post-handshake authentication, are unaffected.
AnalysisAI
Post-handshake authentication bypass in wolfSSL TLS 1.3 permits a connected client to skip certificate verification during server-initiated post-handshake re-authentication. When a server has issued a post-handshake CertificateRequest via wolfSSL_request_certificate(), a client can send a Finished message without providing a Certificate or CertificateVerify; the server incorrectly applies an initial-handshake exemption and accepts it, treating the client as authenticated. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires all of the following non-default conditions to be true simultaneously: (1) the wolfSSL library must be compiled with WOLFSSL_POST_HANDSHAKE_AUTH defined (enabled via --enable-postauth or the umbrella --enable-all flag - not present in a standard minimal build); (2) the server application must have enabled WOLFSSL_VERIFY_POST_HANDSHAKE at runtime; and (3) the server application must explicitly call wolfSSL_request_certificate() after the initial TLS 1.3 handshake completes to trigger a post-handshake CertificateRequest. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 4.0 score of 6.0 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N) reflects a moderate-severity issue where the AT:P (Attack Prerequisites) designation appropriately captures the very narrow exploitation surface. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker establishes a TLS 1.3 connection to a vulnerable wolfSSL server configured to use post-handshake authentication. After the initial handshake completes, the server sends a CertificateRequest to re-authenticate the client. … |
| Remediation | Apply the upstream fix from GitHub PR #10702 (https://github.com/wolfSSL/wolfssl/pull/10702) and monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for the official patched release version, which is not yet confirmed from available data - do not assume the PR merge corresponds to a tagged release. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
wolfSSL prior to version 3.12.2 provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange i
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting
wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or tra
In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. Rated high severity (
An issue was discovered in wolfSSL before 5.5.0. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
wolfSSL 4.3.0 has mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Ra
In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data wh
An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Rated high severity (CVSS 7.0).
wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in t
wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CR
An issue was discovered in wolfSSL before 5.5.0 (when --enable-session-ticket is used); however, only version 5.3.0 is e
wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure outcome when the serial number in an OCSP request di
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today