CVE-2026-3547 in wolfSSL
Summary
by MITRE • 03/20/2026
Out-of-bounds read in ALPN parsing due to incomplete validation. wolfSSL 5.8.4 and earlier contained an out-of-bounds read in ALPN handling when built with ALPN enabled (HAVE_ALPN / --enable-alpn). A crafted ALPN protocol list could trigger an out-of-bounds read, leading to a potential process crash (denial of service). Note that ALPN is disabled by default, but is enabled for these 3rd party compatibility features: enable-apachehttpd, enable-bind, enable-curl, enable-haproxy, enable-hitch, enable-lighty, enable-jni, enable-nginx, enable-quic.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/24/2026
The vulnerability identified as CVE-2026-3547 represents a critical out-of-bounds read condition within the wolfSSL library's Application-Layer Protocol Negotiation implementation. This flaw specifically affects versions 5.8.4 and earlier, where the library fails to properly validate ALPN protocol lists during parsing operations. The issue manifests when wolfSSL is compiled with ALPN support through the HAVE_ALPN configuration flag or the --enable-alpn build option, creating a potential attack surface that adversaries can exploit through carefully crafted protocol lists.
The technical root cause of this vulnerability lies in insufficient input validation during ALPN protocol list parsing. When wolfSSL processes ALPN data structures, it does not adequately verify the boundaries of protocol names within the list, allowing maliciously constructed protocol identifiers to exceed allocated memory boundaries. This incomplete validation creates a scenario where memory access occurs beyond the intended buffer limits, resulting in an out-of-bounds read condition that can trigger memory corruption and subsequent process termination.
From an operational perspective, this vulnerability presents significant risks to systems utilizing wolfSSL with ALPN support enabled. The affected configurations include numerous third-party integrations such as Apache HTTPD, BIND, cURL, HAProxy, Hitch, Lighttpd, JNI, Nginx, and QUIC implementations. These applications become vulnerable when they incorporate wolfSSL with ALPN functionality enabled, creating widespread exposure across various network services and applications. The impact of exploitation results in denial of service conditions where targeted processes crash and become unavailable, disrupting service continuity and potentially enabling more sophisticated attacks.
The vulnerability aligns with CWE-129, which specifically addresses insufficient validation of length of inputs to buffers, and represents a classic example of improper input validation that leads to memory safety issues. From an ATT&CK framework perspective, this vulnerability could be leveraged as part of a reconnaissance phase to identify vulnerable systems, followed by a denial of service attack pattern that would degrade service availability. The attack vector requires the presence of ALPN-enabled wolfSSL configurations, making it a configuration-dependent vulnerability that security teams must actively monitor and address through proper patch management.
Mitigation strategies should prioritize immediate patching of wolfSSL installations to versions beyond 5.8.4 where the ALPN validation has been corrected. Organizations should also conduct comprehensive inventory audits to identify all systems utilizing wolfSSL with ALPN support enabled, particularly focusing on the third-party applications mentioned in the vulnerability description. Additionally, implementing network monitoring to detect unusual ALPN protocol list patterns and establishing automated patch management processes will help reduce the window of exposure. Security teams should consider disabling ALPN support in wolfSSL configurations when it is not required for specific applications, as this serves as an effective temporary workaround while permanent patches are deployed.