EUVD-2026-39560
GHSA-w3gw-f9wr-g6qx
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/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:Clear
Network vector for TLS certificate processing, high complexity due to MitM or chain-influence requirement, low privilege to interact with certificate path; integrity-only low impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
Certificate policy and RFC 8446 compliance concerns regarding the continued acceptance of SHA-1/MD5 in certificate processing.
AnalysisAI
wolfSSL's certificate chain verification accepted MD5-signed certificates when MD5 was compiled in for any purpose (e.g., TLS 1.0 PRF or HMAC), violating RFC 8446 compliance and the fundamental prohibition on broken hash algorithms in certificate signatures. An attacker with low-level positioning who can influence the certificate chain presented to a wolfSSL-based application could potentially bypass chain integrity checks by presenting an MD5-signed leaf certificate. No public exploit has been identified and no CISA KEV listing exists; the CVSS 4.0 score of 2.3 reflects the high complexity and constrained impact of realistic exploitation.
Technical ContextAI
The root cause is CWE-327 (Use of a Broken or Risky Cryptographic Algorithm): wolfSSL's HashForSignature() function in wolfcrypt/src/asn.c did not differentiate between MD5 usage for certificate signature verification versus other permitted uses such as TLS 1.0 PRF or HMAC. The fix adds an explicit guard in verify mode that returns HASH_TYPE_E when MD5 is encountered as a certificate signature algorithm, unless the opt-in build macro WOLFSSL_ALLOW_MD5_CERT_SIGS is defined. Affected product is identified by CPE cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*, indicating all wolfSSL versions prior to the patched build. RFC 8446 (TLS 1.3) and longstanding industry consensus prohibit MD5 and SHA-1 for digital signatures due to demonstrated collision vulnerabilities; wolfSSL's prior behavior left this enforcement gap.
RemediationAI
Rebuild wolfSSL using the patched source code from GitHub PR #10222 (https://github.com/wolfSSL/wolfssl/pull/10222), which adds MD5 rejection logic in HashForSignature() for certificate verify mode. An exact tagged release containing this fix has not been confirmed from available references - monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for the corresponding release advisory. As a compensating control, ensure wolfSSL is compiled without the WOLFSSL_ALLOW_MD5_CERT_SIGS macro, which if defined would re-enable acceptance of MD5 certificate signatures and negate the fix. Operators can validate remediation by running the new test_wolfSSL_CertManagerRejectMD5Cert test case, which constructs an MD5-signed leaf and confirms it is rejected with HASH_TYPE_E. For deployments where patching is not immediately possible, enforcing certificate pinning or restricting accepted CAs at the application layer reduces exposure.
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 technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today