CVE-2026-55962

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

{"affected": [{"affectedData": [{"collectionURL": "https://github.com/wolfSSL/wolfssl", "defaultStatus": "unaffected", "product": "wolfSSL", "vendor": "wolfSSL", "versions": [{"lessThanOrEqual": "5.9.1", "status": "affected", "version": "5.5.4", "versionType": "semver"}]}], "source": "facts@wolfssl.com"}], "configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*", "matchCriteriaId": "DB466E76-3718-40FF-B548-B24B95165D9D", "versionEndExcluding": "5.9.2", "versionStartIncluding": "5.5.4", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "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."}], "id": "CVE-2026-55962", "lastModified": "2026-06-27T19:57:59.510", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 6.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N", "version": "3.1"}, "exploitabilityScore": 2.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}], "cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "PRESENT", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 6.0, "baseSeverity": "MEDIUM", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "LOW", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "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/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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "facts@wolfssl.com", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-55962", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-06-26T10:30:28.816026Z", "version": "2.0.3"}}]}, "published": "2026-06-25T22:17:02.260", "references": [{"source": "facts@wolfssl.com", "tags": ["Issue Tracking", "Patch"], "url": "https://github.com/wolfSSL/wolfssl/pull/10702"}, {"source": "facts@wolfssl.com", "tags": ["Vendor Advisory"], "url": "https://www.wolfssl.com/docs/security-vulnerabilities/"}], "sourceIdentifier": "facts@wolfssl.com", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-287"}], "source": "facts@wolfssl.com", "type": "Secondary"}, {"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[5.5.4,5.9.1]"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "wolfSSL", "source": "cna", "vendor": "wolfSSL"}, "product": "wolfssl", "vendor": "wolfssl"}], "created": "2026-06-25T23:00:14.373915+00:00", "updated": "2026-08-13T14:15:05.240030+00:00", "vendors": ["wolfssl", "wolfssl$PRODUCT$wolfssl"]}