CVE-2026-5501: WolfSSL Information Disclosure Flaw

CVE-2026-5501 Overview

CVE-2026-5501 is a certificate validation flaw in wolfSSL's OpenSSL compatibility layer. The wolfSSL_X509_verify_cert function accepts certificate chains in which the leaf certificate's signature is never verified. An attacker who supplies an untrusted intermediate marked with Basic Constraints CA:FALSE, but legitimately signed by a trusted root, can produce arbitrary forged leaf certificates that the function reports as valid with WOLFSSL_SUCCESS / X509_V_OK. The native wolfSSL TLS handshake path (ProcessPeerCerts) is not affected. The issue impacts applications that call the OpenSSL compatibility API directly, including wolfSSL integrations with nginx and HAProxy.

Critical Impact

An attacker holding any leaf certificate from a trusted CA, such as a free Let's Encrypt DV certificate, can forge certificates for arbitrary subject names with arbitrary public keys and bypass authentication.

Affected Products

• wolfSSL wolfssl library (OpenSSL compatibility layer)
• nginx deployments built against vulnerable wolfSSL
• HAProxy deployments built against vulnerable wolfSSL

Discovery Timeline

• 2026-04-10 - CVE-2026-5501 published to NVD
• 2026-04-27 - Last updated in NVD database

Technical Details for CVE-2026-5501

Vulnerability Analysis

The flaw resides in wolfSSL_X509_verify_cert, the OpenSSL-compatible chain verification entry point. The function trusts the chain structure provided by the caller without enforcing that each intermediate is actually authorized to sign subordinate certificates. When an attacker presents an intermediate whose Basic Constraints extension explicitly states CA:FALSE, the function still proceeds to validate the chain and skips signature verification on the leaf. The result is that any leaf placed beneath such an intermediate is accepted as if it were properly signed.

This weakness aligns with [CWE-295: Improper Certificate Validation]. It defeats the foundational PKI invariant that only certificates marked as CAs in their Basic Constraints can issue further certificates.

Root Cause

The compatibility layer fails to enforce Basic Constraints CA:TRUE on intermediates and fails to verify the leaf signature against the intermediate's public key. The native handshake path in ProcessPeerCerts performs these checks correctly, so the divergence between code paths is the source of the bypass.

Attack Vector

An attacker obtains any standard leaf certificate from a public CA, for example a Domain Validation certificate from Let's Encrypt. They construct a forged "leaf" certificate naming any victim subject with any attacker-controlled public key and arbitrary signature bytes. They then present a chain of [forged leaf] → [their legitimate DV cert acting as intermediate] → [trusted root]. Applications calling wolfSSL_X509_verify_cert return X509_V_OK, allowing TLS client impersonation, mutual TLS bypass, or signature acceptance in any verifier built on this API.

No synthetic exploit code is included here. See the wolfSSL pull request #10102 for the corrective code changes.

Detection Methods for CVE-2026-5501

Indicators of Compromise

• TLS sessions presenting certificate chains where an intermediate has Basic Constraints CA:FALSE yet is used to sign a subsequent certificate.
• Successful authentication events to wolfSSL-backed services using certificates whose subject names do not match any issued inventory record.
• Repeated TLS handshakes from unexpected client identities against nginx or HAProxy endpoints built with the wolfSSL OpenSSL compatibility layer.

Detection Strategies

• Inspect captured TLS handshakes and parse presented chains; flag any chain where a non-CA certificate appears as an issuer.
• Compare authenticated client certificate subjects against the authoritative PKI inventory and alert on mismatches.
• Audit application binaries and packages for linkage against vulnerable wolfSSL versions prior to the fix in pull request 10102.

Monitoring Recommendations

• Log full peer certificate chains at the reverse proxy or load balancer for forensic review.
• Monitor anomalous certificate issuer fields in mTLS authentication events and correlate with user or service identity baselines.
• Track wolfSSL package versions across the fleet and alert when unpatched builds are deployed.

How to Mitigate CVE-2026-5501

Immediate Actions Required

• Upgrade wolfSSL to the fixed release that incorporates pull request #10102 and rebuild dependent applications including nginx and HAProxy.
• Inventory every binary linked against wolfSSL's OpenSSL compatibility layer and prioritize internet-facing TLS terminators.
• Revoke and reissue any client or server certificates whose private keys may have been used for fraudulent authentication during the exposure window.

Patch Information

The wolfSSL project addressed the issue in GitHub pull request #10102. The fix enforces Basic Constraints CA:TRUE on intermediates and ensures the leaf signature is verified against the issuing certificate's public key inside wolfSSL_X509_verify_cert.

Workarounds

• Where patching is delayed, route certificate verification through the native wolfSSL handshake path (ProcessPeerCerts) rather than the OpenSSL compatibility API.
• Pin expected peer certificate fingerprints in applications that perform mTLS so that forged chains fail an additional out-of-band check.
• Restrict accepted issuer CAs to a private internal CA where feasible to remove public DV certificates from the trust path.