EUVD-2026-39491
GHSA-cj56-5c53-9qjf
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/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
Network-reachable with no auth or interaction, but AC:H reflects the requirement that the app feed attacker-controlled PKCS#7 to the compat verify API; impact is integrity-only (signature bypass), no C or A loss.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
wolfSSL_PKCS7_verify() returning success for a degenerate (certs-only) PKCS#7 object that contains no signer. Such an object has empty signerInfos, so the underlying signed-data verification succeeds without authenticating any content. The compatibility-layer verify path now rejects the object when no signer signature has actually been verified, so a PKCS#7 carrying no valid signature is no longer reported as verified. This is enforced regardless of the PKCS7_NOVERIFY flag, which only suppresses signer certificate chain validation and was never intended to waive the requirement that a signature exist. Only affects OpenSSL compatibility builds that call the PKCS7_verify() compatibility API on potentially degenerate PKCS#7 bundles.
AnalysisAI
Signature-verification bypass in wolfSSL's OpenSSL compatibility layer allows a degenerate (certs-only) PKCS#7 object - one with empty signerInfos and no actual signature - to be falsely reported as verified by wolfSSL_PKCS7_verify(). Applications using the PKCS7_verify() compat API to authenticate attacker-supplied PKCS#7/CMS bundles can be tricked into treating unsigned content as authentic, undermining integrity guarantees. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the underlying defect is a classic improper-signature-verification (CWE-347) issue with a CVSS 4.0 base score of 8.2.
Technical ContextAI
The flaw lives in wolfSSL's OpenSSL compatibility shim (src/ssl_p7p12.c), specifically the wolfSSL_PKCS7_verify() emulation of OpenSSL's PKCS7_verify(). PKCS#7 / CMS SignedData structures can legitimately be 'degenerate' - carrying only certificates and CRLs with an empty set of signerInfos (commonly used to ship a cert bundle, e.g. as in openssl crl2pkcs7). The internal primitive wc_PKCS7_VerifySignedData() returns success on such an object because there is technically nothing to fail: with no SignerInfo there is no signature to check. The compat wrapper previously mapped that internal success directly to WOLFSSL_SUCCESS, so 'no signer' was indistinguishable from 'signer verified.' The root cause is CWE-347 (Improper Verification of Cryptographic Signature): the absence of a signature was conflated with a valid signature. The CPE cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:* indicates the wolfSSL library itself across versions, but only OpenSSL-compatibility builds that expose and call PKCS7_verify() are reachable. The fix adds a guard checking p7->pkcs7.verifyCert (set only after a signer's signature is actually verified) and returns WOLFSSL_FAILURE when it is NULL, enforced even under the PKCS7_NOVERIFY flag - clarifying that NOVERIFY waives signer chain validation, not the requirement that a signature exist.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply the change from wolfSSL pull request https://github.com/wolfSSL/wolfssl/pull/10702 and track the wolfSSL security advisory page https://www.wolfssl.com/docs/security-vulnerabilities/ for the tagged release that includes it, then upgrade to that version. As a compensating control until you can update, applications should not trust the boolean result of PKCS7_verify() alone: explicitly reject PKCS#7/CMS objects that contain zero SignerInfos (degenerate, certs-only bundles) before treating content as authenticated, and verify that at least one signer was actually validated. Do not rely on the PKCS7_NOVERIFY flag to imply any signature checking - it only suppresses certificate-chain validation. If feasible, constrain inputs so only structures with an expected signer reach the verify path; the trade-off is added application-side parsing/validation logic and potential rejection of legitimate certs-only bundles your workflow may have relied on.
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe
The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se
The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not pro
The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak
The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a
The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly
A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig
The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before
In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today