EUVD-2026-39580
GHSA-h4jr-6mf9-63fq
Severity by source
CVSS:4.0/AV:A/AC:L/AT:P/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Certificate presentation occurs over any network so AV:N; AC:H for non-default build flag and IP nameConstraints deployment requirement; PR:H for CA-level issuance authority; integrity-only PKI bypass, no confidentiality or availability impact.
Primary rating from Vendor (wolfSSL).
CVSS VectorVendor: wolfSSL
Lifecycle Timeline
2DescriptionCVE.org
iPAddress name constraints bypass when WOLFSSL_IP_ALT_NAME is not defined. IP address name constraints are not enforced in that configuration, allowing a certificate to bypass an issuing CA's IP address constraints.
AnalysisAI
Certificate IP address name constraint enforcement in wolfSSL is silently disabled when the library is compiled without the WOLFSSL_IP_ALT_NAME preprocessor define, allowing a CA operator to issue certificates bearing IP address Subject Alternative Names that the issuing CA's nameConstraints extension was intended to prohibit. Any wolfSSL-based TLS endpoint built in this configuration will accept these constraint-violating certificates as valid, undermining PKI-enforced IP address restrictions. No public exploit has been identified and this vulnerability is not listed in CISA KEV; the CVSS 4.0 score of 5.7 reflects meaningful exploitation constraints including high-privilege CA access and a specific non-default build configuration.
Technical ContextAI
wolfSSL (CPE: cpe:2.3:a:wolfssl:wolfssl:*:*:*:*:*:*:*:*) is a lightweight SSL/TLS library for embedded and resource-constrained environments. RFC 5280 Section 4.2.1.10 defines the nameConstraints X.509v3 extension, allowing CAs to restrict subordinate certificates to permitted name subtypes including IP address ranges. In wolfSSL, the iPAddress SAN processing path inside CheckForAltNames (src/internal.c) is conditionally compiled under the WOLFSSL_IP_ALT_NAME macro. When that macro is absent, the iPAddress branch is excluded at compile time, causing the CN-fallback logic to treat iPAddress SAN entries as non-existent and skipping IP address name constraint checks entirely. The fix in PR #10354 introduces explicit type filtering so iPAddress entries are treated as absent from hostname matching without WOLFSSL_IP_ALT_NAME, while also correcting registeredID (RID) SAN handling - making those unconditionally available to ConfirmNameConstraints for RFC 5280 RID name constraint enforcement, independent of the WOLFSSL_RID_ALT_NAME build flag. CWE-295 (Improper Certificate Validation) correctly classifies this as a failure to enforce issuer-mandated certificate policy through an incomplete conditional compilation boundary.
RemediationAI
Apply the upstream fix from wolfSSL GitHub PR #10354 (https://github.com/wolfSSL/wolfssl/pull/10354) once it is merged into a tagged release - a specific patched version number has not been independently confirmed from available data, so monitor https://www.wolfssl.com/docs/security-vulnerabilities/ for the confirmed fix release. As an immediate compensating control where recompilation is feasible, add WOLFSSL_IP_ALT_NAME to the build configuration; this re-enables the iPAddress SAN processing path and restores IP address name constraint enforcement, but may alter certificate selection behavior for end-entity certificates that present only iPAddress SANs and no DNS SANs - validate application TLS behavior in a test environment before deploying to production. If IP address name constraints are not in use within your PKI (i.e., no CA certificate in your chain contains a nameConstraints extension with permitted or excluded IP subtrees), the immediate operational impact of this vulnerability is negligible, but the fix should still be applied to maintain RFC 5280 compliance.
wolfSSL prior to version 3.12.2 provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange i
A specially crafted x509 certificate can cause a single out of bounds byte overwrite in wolfSSL through 3.10.2 resulting
wolfSSL (formerly CyaSSL) before 3.6.8 allows remote attackers to cause a denial of service (resource consumption or tra
In wolfSSL before 5.5.1, malicious clients can cause a buffer overflow during a TLS 1.3 handshake. Rated high severity (
An issue was discovered in wolfSSL before 5.5.0. Rated high severity (CVSS 7.5), this vulnerability is remotely exploita
wolfSSL 4.3.0 has mulmod code in wc_ecc_mulmod_ex in ecc.c that does not properly resist timing side-channel attacks. Ra
In wolfSSL 4.1.0 through 4.2.0c, there are missing sanity checks of memory accesses in parsing ASN.1 certificate data wh
An issue was discovered in wolfSSL before 4.5.0, when single precision is not employed. Rated high severity (CVSS 7.0).
wolfSSL before 4.5.0 mishandles TLS 1.3 server data in the WAIT_CERT_CR state, within SanityCheckTls13MsgReceived() in t
wolfSSL (formerly CyaSSL) before 3.6.8 does not properly handle faults associated with the Chinese Remainder Theorem (CR
An issue was discovered in wolfSSL before 5.5.0 (when --enable-session-ticket is used); however, only version 5.3.0 is e
wolfSSL 4.6.x through 4.7.x before 4.8.0 does not produce a failure outcome when the serial number in an OCSP request di
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today