EUVD-2026-87923
GHSA-f972-pmrg-c63r
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/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 MITM with no auth (PR:N/UI:N); AC:H because it needs non-default OCSP-multi config plus an attacker cert+key chaining to a trusted CA; full impersonation gives C:H/I:H, no availability effect.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
3DescriptionCVE.org
In wolfSSL versions 5.7.2 through 5.9.2 there is a client-side implementation flaw in RFC 6961, multiple OCSP response stapling, which can lead to certificate forgery. When a wolfSSL client enables OCSP stapling with the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), the client accepts any certificate in the peer's chain as a certificate authority without verifying that the certificate is actually authorized to act as one. This means that an attacker who possesses any certificate that chains to a CA trusted by the client (along with its private key) can forge certificates for arbitrary identities that will be accepted as valid by the client. The end entity certificate of the server is stored in the persistent trust store, affecting subsequent connections that reuse the context even when OCSP multi usage is not employed. Found by internal wolfSSL testing.
AnalysisAI
Certificate forgery in the wolfSSL client (versions 5.7.2 through 5.9.2) lets a remote attacker who already holds any certificate and matching private key that chains to a CA the client trusts mint certificates for arbitrary identities that the affected client accepts as valid, enabling full TLS man-in-the-middle of connections that client initiates. The defect is reachable only in a non-default configuration: a client build with HAVE_CERTIFICATE_STATUS_REQUEST_V2 that explicitly enables RFC 6961 multiple OCSP stapling via wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options); in addition, the attacker-supplied end-entity certificate can be written into the persistent trust store held by the shared WOLFSSL_CTX, so later connections that reuse that context stay affected even when multi-stapling is no longer in use. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
No credit card · 7-day full trial
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires a wolfSSL CLIENT built with HAVE_CERTIFICATE_STATUS_REQUEST_V2 that explicitly enables RFC 6961 multiple OCSP stapling via wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options) - this is a non-default configuration. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | This is a genuine certificate-validation defect (CWE-295) that enables full TLS man-in-the-middle, not merely an information leak, so it should be treated as a real priority for the subset of deployments that match the trigger conditions. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Apply the upstream fix tracked in PR #11027 (https://github.com/wolfSSL/wolfssl/pull/11027); upstream fix available (PR/commit); released patched version not independently confirmed in the available data, so verify which wolfSSL release bundles PR #11027 before relying on a version number rather than the commit. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all wolfSSL client deployments and identify any builds in versions 5.7.2 through 5.9.2 compiled with HAVE_CERTIFICATE_STATUS_REQUEST_V2 that call wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options); disable RFC 6961 multiple OCSP stapling or rebuild those clients without the flag, and purge or rotate the persistent trust store on any shared WOLFSSL_CTX that may have accepted an attacker-supplied end-entity certificate. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
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
Authentication bypass in wolfSSL TLS clients built with Raw Public Key (RPK) support allows a malicious or on-path serve
wolfSSL builds that enable the WOLFSSL_TRUST_PEER_CERT macro can be induced to accept a forged clone of a trusted-peer C
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
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today