Talos Vulnerability Report

Summary

A improper input validation vulnerability exists in the X.509 iPAddress name constraints enforcement functionality of wolfSSL (version(s): 5.9.1). A specially crafted X.509 certificate chain can lead to bypass of iPAddress name constraints. An attacker can present a certificate with an IP SAN outside the CA’s permitted iPAddress range to trigger this vulnerability.

Confirmed Vulnerable Versions

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

wolfSSL (version(s): 5.9.1)

Product URLs

wolfSSL - https://www.wolfssl.com/

CVSSv3 Score

9.1 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CWE

CWE-295 - Improper Certificate Validation

Details

wolfSSL is a lightweight, portable C-language SSL/TLS library targeted at IoT, embedded and RTOS environments due to its small size and high performance. It supports the latest security standards, including TLS 1.3 and DTLS 1.2, while maintaining a footprint significantly smaller than traditional libraries like OpenSSL.

Within its wolfcrypt package, wolfSSL supports a variety of operations, including validation for X.509 certificates. In some configurations wolfSSL will silently fail to add IP Address GeneralName mappings to the certificate’s alternative names list, causing IP addresses outside of the permitted range to be treated as valid.

We see this starting at [1] inside DecodeGeneralName. When wolfSSL is attempting to set a DNS entry for a given IP Address, the SAN parser that populates cert->altNames with IP entries is gated on WOLFSSL_IP_ALT_NAME. Without WOLFSSL_IP_ALT_NAME the else if block for ASN_IP_TYPE is compiled out, causing any certificate containing an iPAddress SAN (tag 0x87) to be silently skipped.

static int DecodeGeneralName(const byte* input, word32* inOutIdx, byte tag,
                             int len, DecodedCert* cert)
{
    int ret = 0;
    word32 idx = *inOutIdx;

    /* GeneralName choice: dnsName */
    if (tag == (ASN_CONTEXT_SPECIFIC | ASN_DNS_TYPE)) {
        ret = SetDNSEntry(cert->heap, (const char*)(input + idx), len,
                ASN_DNS_TYPE, &cert->altNames);
        if (ret == 0) {
            idx += (word32)len;
        }
    }
...
    #ifdef WOLFSSL_IP_ALT_NAME                                                                   [1]
    /* GeneralName choice: iPAddress */
    else if (tag == (ASN_CONTEXT_SPECIFIC | ASN_IP_TYPE)) {
        ret = SetDNSEntry(cert->heap, (const char*)(input + idx), len,
                ASN_IP_TYPE, &cert->altNames);
        if (ret == 0) {
            idx += (word32)len;
        }
    }
    #endif /* WOLFSSL_IP_ALT_NAME */

This poses an issue at constraint-check time. The ConfirmNameConstraints function checks certificates against the issuing CA’s nameConstraints extension where it iterates over each name type walking the certificate’s parsed SAN list looking for matching entries to validate. For ASN_IP_TYPE, the checker reads from cert->altNames at [2], the same list used for ASN_DNS_TYPE and ASN_URI_TYPE types.

static int ConfirmNameConstraints(Signer* signer, DecodedCert* cert)
{
    ...
    for (i=0; i < (int)sizeof(nameTypes); i++) {
        byte nameType = nameTypes[i];
        DNS_entry* name = NULL;
        DNS_entry  subjectDnsName; /* temporary node used for subject name */

        XMEMSET(&subjectDnsName, 0, sizeof(DNS_entry));
        switch (nameType) {
            case ASN_DNS_TYPE:
                /* Should it also consider CN in subject? It could use
                 * subjectDnsName too */
                name = cert->altNames;
                break;
            case ASN_IP_TYPE:
                /* IP addresses are stored in altNames with type ASN_IP_TYPE */
                name = cert->altNames;                                                           [2]
                break;
            ...
        }

        while (name != NULL) {
            /* Only check entries that match the current nameType. */
            if (name->type == nameType) {                                                        [3]
                if (IsInExcludedList(name, signer->excludedNames,
                        nameType) == 1) {
                    WOLFSSL_MSG("Excluded name was found!");
                    return 0;
                }

                /* Check against the permitted list */
                if (PermittedListOk(name, signer->permittedNames,
                        nameType) != 1) {
                    WOLFSSL_MSG("Permitted name was not found!");
                    return 0;
                }
            }

            name = name->next;
        }

In cases where WOLFSSL_IP_ALT_NAME was not defined at compile time, causing the ASN_IP_TYPE tag SetDNSEntry routine to never run, cert->altNames will not contain any ASN_IP_TYPE General Names. This will result in those values not getting checked at [3] for exclusions and subsequently being treated as valid.

Take the example where a CA certificate constrains the permitted iPAddress to 192.168.1.0/255.255.255.0 but a leaf cert has SAN IP:10.0.0.1 (outside permitted range). In this case OpenSSL rejects with error 47: permitted subtree violation whereas wolfSSL’s default build will accept the cert as valid.

By default the --enable-ip-alt-name flag is false, causing WOLFSSL_IP_ALT_NAME to not be defined and presenting the vulnerable condition. Users of the library can mitigate this vulnerability by enabling the --enable-ip-alt-name flag at compile time, or using a build that already enables it.

Vendor Response (CVE-2026-7532)

Vendor Link: https://nvd.nist.gov/vuln/detail/CVE-2026-7532

Vendor Notes: The new release, wolfSSL v5.9.2, release June 23, 2026.

Timeline

2026-04-29 - Initial Vendor Contact
2026-04-29 - Vendor Disclosure
2026-06-23 - Vendor Patch Release
2026-07-01 - Public Release