157 lines
8.0 KiB
JSON
157 lines
8.0 KiB
JSON
{
|
|
"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"
|
|
}
|
|
}
|
|
]
|
|
}
|
|
} |