Cyber Posture

CVE-2026-5501

High

Published: 10 April 2026

Published
10 April 2026
Modified
27 April 2026
KEV Added
Patch
CVSS Score 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
EPSS Score 0.0002 5.6th percentile
Risk Priority 16 60% EPSS · 20% KEV · 20% CVSS

Description

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.

Mitigating Controls (NIST 800-53 r5)AI

prevent

Directly requires timely identification, reporting, and patching of the specific flaw in wolfSSL_X509_verify_cert that allows forged certificate chains.

prevent

Mandates establishment and management of PKI certificates with defined validation methods to prevent acceptance of malformed chains lacking leaf signature verification.

prevent

Requires verification that security functions, including certificate chain validation in the OpenSSL compatibility layer, operate as intended to mitigate improper validation flaws.

Security SummaryAI

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.

Details

CWE(s)

Affected Products

wolfssl
wolfssl
≤ 5.9.0

MITRE ATT&CK Enterprise TechniquesAI

T1190 Exploit Public-Facing Application Initial Access
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.
T1557 Adversary-in-the-Middle Credential Access
Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as [Network Sniffing](https://attack.
Why these techniques?

Vulnerability enables remote exploitation of public-facing apps (nginx/haproxy) via malformed cert chains (T1190) and directly facilitates MITM/impersonation by bypassing X.509 validation (T1557).

Confidence: MEDIUM · MITRE ATT&CK Enterprise v18.1

References