Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/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:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-5501 is a high-severity Improper Certificate Validation (CWE-295) vulnerability in Wolfssl Wolfssl. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Security Account Manager (T1003.002); ranked at the 12th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-17 (Public Key Infrastructure Certificates) and SC-23 (Session Authenticity) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-5501 is a high-severity vulnerability (CVSS 8.1, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) in the wolfSSL_X509_verify_cert function within wolfSSL's OpenSSL compatibility layer. The flaw allows acceptance of a malformed certificate chain where the leaf certificate's signature is not verified if an attacker provides an untrusted intermediate certificate with Basic Constraints CA:FALSE that is legitimately signed by a trusted root. This issue is confined to applications directly using the OpenSSL compatibility API and does not affect wolfSSL's native TLS handshake path (ProcessPeerCerts). Affected integrations include wolfSSL embedded in nginx and haproxy.
An attacker with low privileges and network access can exploit this by obtaining a legitimate leaf certificate from a trusted CA, such as a free Domain Validation certificate from Let's Encrypt. They can then forge a certificate for any subject name, embed any public key, and include arbitrary signature bytes in the chain. When processed by wolfSSL_X509_verify_cert, the function erroneously returns WOLFSSL_SUCCESS or X509_V_OK, enabling high-impact confidentiality and integrity violations, such as impersonation or man-in-the-middle attacks in compatible applications (CWE-295: Improper Certificate Validation).
Mitigation is addressed in a patch available via the wolfSSL GitHub pull request at https://github.com/wolfSSL/wolfssl/pull/10102, which security practitioners should review and apply to affected wolfSSL versions using the OpenSSL compatibility layer.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-21294
Vulnerability Data
wolfSSL_X509_verify_cert in the OpenSSL compatibility layer accepts a certificate chain in which the leaf's signature is not checked, if the attacker supplies an untrusted intermediate with Basic Constraints `CA:FALSE` that is legitimately signed by a trusted root. An attacker who…
more
obtains any leaf certificate from a trusted CA (e.g. a free DV cert from Let's Encrypt) can forge a certificate for any subject name with any public key and arbitrary signature bytes, and the function returns `WOLFSSL_SUCCESS` / `X509_V_OK`. The native wolfSSL TLS handshake path (`ProcessPeerCerts`) is not susceptible and the issue is limited to applications using the OpenSSL compatibility API directly, which would include integrations of wolfSSL into nginx and haproxy.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 12 hardening rules · 3 OS baselines
—
Mitigating Controls (NIST 800-53 r5) AI
PKI certificate issuance and acquisition under an approved policy establishes the trusted roots and processes needed for correct validation.
Protecting session authenticity depends on cryptographic mechanisms whose trust depends on correct certificate validation.
Requiring confidentiality and integrity protection of transmitted data drives use of properly validated certificates in protocols such as TLS.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Assessing authenticity/integrity of acquired software often relies on code-signing certificate validation.
Certificate-based authentication of users/services/hardware directly depends on correct validation.
Identity assertions conveyed via certificates require validation to be verified.
Proper certificate validation is a core mechanism for protecting data-in-transit confidentiality and integrity.
Secure development practices explicitly include implementing correct certificate validation logic.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (higher-evidence rows only; rows rated `none` are excluded).
Oracle Linux 8 (3 rules)
- V-248574 YUM must be configured to prevent the installation of patches, service packs, device drivers, or OL 8 system components that have not been digitally signed using a certificate that is recognized and approved by the organization. blocks CWE-295
- V-248531 OL 8, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. blocks CWE-295
- V-248575 OL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. blocks CWE-295
RHEL 7 (2 rules)
- V-204447 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. blocks CWE-295
- V-204448 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. blocks CWE-295
RHEL 8 (2 rules)
- V-230264 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. blocks CWE-295
- V-230265 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. blocks CWE-295