{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-55962","assignerOrgId":"50d2cd11-d01a-48ed-9441-5bfce9d63b27","state":"PUBLISHED","assignerShortName":"wolfSSL","dateReserved":"2026-06-17T22:10:55.453Z","datePublished":"2026-06-25T21:12:38.074Z","dateUpdated":"2026-06-26T10:31:12.017Z"},"containers":{"cna":{"providerMetadata":{"orgId":"50d2cd11-d01a-48ed-9441-5bfce9d63b27","shortName":"wolfSSL","dateUpdated":"2026-06-25T21:12:38.074Z"},"title":"TLS 1.3 post-handshake authentication: server accepts Finished without client Certificate/CertificateVerify","problemTypes":[{"descriptions":[{"lang":"en","cweId":"CWE-287","description":"CWE-287 Improper Authentication","type":"CWE"}]}],"affected":[{"vendor":"wolfSSL","product":"wolfSSL","collectionURL":"https://github.com/wolfSSL/wolfssl","versions":[{"status":"affected","version":"5.5.4","lessThanOrEqual":"5.9.1","versionType":"semver"}],"defaultStatus":"unaffected"}],"descriptions":[{"lang":"en","value":"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.","supportingMedia":[{"type":"text/html","base64":false,"value":"<p>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.</p>"}]}],"references":[{"url":"https://github.com/wolfSSL/wolfssl/pull/10702","tags":["patch"]},{"url":"https://www.wolfssl.com/docs/security-vulnerabilities/"}],"metrics":[{"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}],"cvssV4_0":{"attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"PRESENT","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"NONE","subConfidentialityImpact":"NONE","vulnIntegrityImpact":"HIGH","subIntegrityImpact":"NONE","vulnAvailabilityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED","version":"4.0","baseSeverity":"MEDIUM","baseScore":6,"vectorString":"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"}}],"credits":[{"lang":"en","value":"NVIDIA Project Vanessa","type":"finder"}],"source":{"discovery":"UNKNOWN"},"x_generator":{"engine":"Vulnogram 1.0.2"}},"adp":[{"metrics":[{"other":{"type":"ssvc","content":{"timestamp":"2026-06-26T10:30:28.816026Z","id":"CVE-2026-55962","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}}],"title":"CISA ADP Vulnrichment","providerMetadata":{"orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP","dateUpdated":"2026-06-26T10:31:12.017Z"}}]}}