wolfSSL CVE-2026-55961

Exploitation requires that the target application is built with wolfSSL's OpenSSL compatibility layer AND calls the PKCS7_verify() / wolfSSL_PKCS7_verify() API on PKCS#7 bundles whose contents an attacker can influence. The attacker must supply a degenerate certs-only PKCS#7 SignedData object with empty signerInfos (no signer signature). No authentication, privileges, or user interaction are needed (PR:N/UI:N), but the AT:P attack requirement means it only works where the application accepts and verifies externally provided PKCS#7 data and acts on the success/failure result. Limiting factors: wolfSSL builds without the OpenSSL PKCS#7 compat layer are unaffected, applications that never call PKCS7_verify() on untrusted input are unaffected, and the PKCS7_NOVERIFY flag does not change exploitability (it never waived the signature-existence requirement).

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N, score 8.2 / High) cleanly matches the defect: network-reachable, no privileges or user interaction, but with an Attack Requirement (AT:P) - the victim application must actually pass a potentially degenerate, attacker-controlled PKCS#7 bundle to the compat verify API. Impact is purely to integrity (VI:H); there is no confidentiality or availability loss, consistent with a signature-acceptance bug rather than memory corruption or data exposure. There is no EPSS score, no KEV listing, and no public POC in the provided data, so this is a high-severity correctness/trust flaw rather than a confirmed mass-exploitation event. Real-world risk is conditional: it only matters for products that build wolfSSL with OpenSSL compatibility and rely on PKCS7_verify() to make trust decisions (e.g. validating signed payloads, JWT/JWS-adjacent or S/MIME-style flows - note the 'Jwt Attack' and 'OpenSSL' tags). For those deployments the impact is serious because the verification routine returns the wrong answer silently. Priority is genuinely high for affected integrators but near-zero for wolfSSL users who never call the PKCS7 compat layer.

An attacker crafts a degenerate PKCS#7 SignedData object containing only certificates (or empty content) and no SignerInfo, then submits it to a network service that authenticates payloads via wolfSSL's PKCS7_verify() compat API. The call returns success, so the service accepts the unsigned content as if it were validly signed, allowing the attacker to spoof a trusted/signed message. No public POC is referenced, and exploitation depends on the target application's use of the vulnerable API on attacker-supplied input (AT:P).