CVE-2026-7532: 
wolfSSL vulnerability analysis and mitigation

CVE-2026-7532 is an improper certificate validation vulnerability in wolfSSL that allows IP address name constraints to be bypassed when the WOLFSSL_IP_ALT_NAME compile-time flag is not defined. In this configuration, iPAddress Subject Alternative Names (SANs) are silently skipped during parsing, causing the ConfirmNameConstraints function to never enforce the issuing CA's permitted or excluded IP address ranges. The vulnerability affects wolfSSL versions up to and including 5.9.1; version 5.9.2 (released June 23, 2026) contains the fix. It carries a CVSS v3.1 base score of 9.1 (Critical) per Cisco Talos and 7.5 (High) per NVD, and a CVSS v4.0 base score of 5.7 (Medium) (Talos, GitHub Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation). In DecodeGeneralName(), the code block that parses iPAddress GeneralNames (ASN tag 0x87) and populates cert->altNames with ASN_IP_TYPE entries is conditionally compiled only when WOLFSSL_IP_ALT_NAME is defined. Because the default build does not enable --enable-ip-alt-name, this block is compiled out, causing any certificate containing an IP SAN to be silently skipped. Consequently, when ConfirmNameConstraints() iterates over cert->altNames to enforce the CA's permitted/excluded subtrees, no ASN_IP_TYPE entries are present, so a leaf certificate with an IP SAN outside the CA's permitted range (e.g., 10.0.0.1 when only 192.168.1.0/24 is permitted) is accepted as valid. The fix, merged in PR #10354, unconditionally parses and stores iPAddress and registeredID GeneralNames, gating only the human-readable string generation behind feature macros (Talos, GitHub PR).

Successful exploitation allows an attacker who controls a certificate with an IP SAN outside the CA's permitted range to have that certificate accepted as valid by a wolfSSL-based application, effectively bypassing a PKI security boundary. The primary impact is a high integrity violation — trust decisions based on IP address name constraints are rendered meaningless, enabling man-in-the-middle attacks or unauthorized service impersonation on IP-constrained networks. There is no confidentiality or availability impact directly from the bypass itself, but the ability to impersonate trusted services could lead to credential theft or interception of sensitive communications in downstream systems (Talos, GitHub Advisory).

1. Identify target: Locate an application or service using wolfSSL built without the --enable-ip-alt-name compile flag (i.e., WOLFSSL_IP_ALT_NAME is undefined), which enforces IP address name constraints via X.509 certificates.
2. Obtain a CA with IP name constraints: Acquire or compromise a CA certificate that includes a nameConstraints extension restricting permitted iPAddress ranges (e.g., permitting only 192.168.1.0/255.255.255.0).
3. Issue a violating leaf certificate: Using the constrained CA, issue a leaf certificate containing an iPAddress SAN outside the permitted range (e.g., IP:10.0.0.1). In a legitimate PKI this would be rejected, but the attacker controls the CA or has obtained a mis-issued cert.
4. Present the certificate: Present the crafted certificate chain to the vulnerable wolfSSL-based application during a TLS handshake or certificate validation operation.
5. Bypass enforced: Because WOLFSSL_IP_ALT_NAME is not defined, the IP SAN is never added to cert->altNames, so ConfirmNameConstraints() finds no IP entries to check and accepts the certificate as valid — enabling service impersonation or man-in-the-middle interception (Talos, GitHub PR).

• Network: TLS connections presenting certificates with iPAddress SANs that fall outside the CA's declared nameConstraints permitted subtrees; unexpected TLS sessions from IP addresses not within the CA-constrained range.
• Logs: Application or TLS library logs showing successful certificate validation for certificates whose IP SANs should have been rejected by name constraint enforcement; absence of "Permitted name was not found!" or "Excluded name was found!" wolfSSL debug messages when IP-constrained certificates are presented.
• File System: Presence of X.509 certificate files with iPAddress SANs outside expected ranges in application certificate stores or trust anchors.
• Configuration: wolfSSL builds lacking the WOLFSSL_IP_ALT_NAME define or built without --enable-ip-alt-name, identifiable via build configuration files or binary strings analysis.

Upgrade wolfSSL to version 5.9.2 or later, which unconditionally parses and enforces iPAddress GeneralNames in name constraint checking (Talos, wolfSSL Security). As an interim workaround for environments that cannot immediately upgrade, rebuild wolfSSL with the --enable-ip-alt-name compile-time flag (which defines WOLFSSL_IP_ALT_NAME), enabling IP SAN parsing and constraint enforcement (Talos). Additionally, review and audit any PKI deployments that rely on IP address name constraints for security boundaries to assess exposure.

Cisco Talos researcher Ankur Tyagi discovered and reported the vulnerability, publishing a detailed technical write-up on July 1, 2026, including code-level analysis of the affected DecodeGeneralName() and ConfirmNameConstraints() functions (Talos). The wolfSSL team responded promptly, with the fix merged on May 8, 2026, and the patched release (v5.9.2) shipped on June 23, 2026, prior to public disclosure. No significant broader community or social media discussion has been observed beyond standard CVE tracking and aggregator coverage.