{"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"}}]}}

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

{}

{}