Talos Vulnerability Report

Summary

A improper input validation vulnerability exists in the X.509 registeredID name constraints enforcement functionality of wolfSSL (version(s): 5.9.1). A specially crafted X.509 certificate chain can lead to bypass registeredID name constraints. An attacker can present a certificate with a registeredID SAN outside the CA’s permitted OID subtree 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

7.4 - CVSS:3.1/AV:N/AC:H/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 all build configurations, wolfSSL silently ignores registeredID entries in a CA’s nameConstraints extension, causing any certificate with a registeredID SAN to bypass constraint enforcement regardless of what the issuing CA specifies.

The failure spans three independent layers. The first is in ConfirmNameConstraints, where the constraint checker iterates over a fixed array of GeneralName types at [1]. The array contains five entries – ASN_RFC822_TYPE, ASN_DNS_TYPE, ASN_DIR_TYPE, ASN_IP_TYPE and ASN_URI_TYPE – but ASN_RID_TYPE is absent entirely.

static int ConfirmNameConstraints(Signer* signer, DecodedCert* cert)
{
    const byte nameTypes[] = {ASN_RFC822_TYPE, ASN_DNS_TYPE,             [1]
                               ASN_DIR_TYPE, ASN_IP_TYPE, ASN_URI_TYPE};

Because ASN_RID_TYPE is never in nameTypes[], the checker loop never considers registeredID entries at all. RFC 5280 Section 4.2.1.10 defines registeredID as a valid GeneralName type in nameConstraints, so any CA certificate that restricts registeredID values will have those constraints silently discarded.

The second layer is in DecodeSubtree, the parser that reads the CA certificate’s nameConstraints extension and stores permitted and excluded subtrees. At [2] the parser gates on a set of known GeneralName tags; the supported set covers DNS, RFC822, DIR, IP and URI. There is no case for registeredID. Any registeredID subtree in the CA’s nameConstraints is silently skipped and never stored in the signer’s permitted or excluded lists.

            /* Check GeneralName tag is one of the types we can handle. */
            if (t == (ASN_CONTEXT_SPECIFIC | ASN_DNS_TYPE) ||
                t == (ASN_CONTEXT_SPECIFIC | ASN_RFC822_TYPE) ||
                t == (ASN_CONTEXT_SPECIFIC | ASN_CONSTRUCTED |            [2]
                     ASN_DIR_TYPE) ||
                t == (ASN_CONTEXT_SPECIFIC | ASN_IP_TYPE) ||
                t == (ASN_CONTEXT_SPECIFIC | ASN_URI_TYPE)) {
                /* Parse the general name and store a new entry. */
                ret = DecodeSubtreeGeneralName(...);
            }
            /* Skip entry. */

The third layer is the SAN parser inside DecodeGeneralName. Parsing of registeredID entries in the leaf certificate is conditionally compiled behind WOLFSSL_RID_ALT_NAME at [3]. Without that define the else if block for ASN_RID_TYPE is compiled out, causing any certificate containing a registeredID SAN (tag 0x88) to be silently skipped and leaving cert->altNames with no ASN_RID_TYPE entries.

    #ifdef WOLFSSL_RID_ALT_NAME                                               [3]
    /* GeneralName choice: registeredID */
    else if (tag == (ASN_CONTEXT_SPECIFIC | ASN_RID_TYPE)) {
        ret = SetDNSEntry(cert->heap, (const char*)(input + idx), len,
                ASN_RID_TYPE, &cert->altNames);
        if (ret == 0) {
            idx += (word32)len;
        }
    }
    #endif /* WOLFSSL_RID_ALT_NAME */

The WOLFSSL_RID_ALT_NAME compile gate at layer three is not the primary failure. Even in a build where the flag is defined – causing the SAN parser to correctly populate cert->altNames with registeredID entries – constraints remain unenforced. Neither DecodeSubtree nor ConfirmNameConstraints has been taught about ASN_RID_TYPE, so the correctly parsed entries are simply never consumed by the enforcement pipeline. The enforcement failure is unconditional across all wolfSSL builds.

Vendor Response (CVE-2026-5263)

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

Vendor Notes: The fix was created in the PR: https://github.com/wolfSSL/wolfssl/pull/10048. The fix was released in v5.9.1.

Timeline

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