Security researchers have disclosed a wave of critical vulnerabilities in wolfSSL, the lightweight SSL/TLS library embedded in billions of web servers, VPNs, industrial controllers, automotive systems, and IoT devices. The flaws span certificate trust bypass, heap buffer overflows, denial-of-service conditions, and weaknesses in post-quantum cryptographic implementations — any one of which could be catastrophic in the environments where wolfSSL is deployed.
What Is wolfSSL?
wolfSSL is a compact, portable SSL/TLS implementation designed for constrained environments where OpenSSL’s footprint is too large. It is embedded in an enormous range of products including embedded web servers, industrial control systems, automotive infotainment units, smart home devices, and VPN appliances. Many products also use wolfCrypt, wolfSSL’s cryptographic engine, which shares several of the reported vulnerabilities. Because wolfSSL underpins TLS communications across billions of endpoints, weaknesses in the library carry internet-scale implications.
Certificate Trust Chain Bypass
Several of the most severe CVEs target wolfSSL’s OpenSSL-compatible certificate verifier, wolfSSL_X509_verify_cert. The vulnerabilities allow attacker-controlled certificates to be accepted as trusted, even when they do not chain back to any configured trust anchor:
- CVE-2026-11310 and CVE-2026-11999: Untrusted intermediate certificates supplied by a caller can anchor a path or exhaust the path depth and still be treated as valid.
- CVE-2026-6091 (partial-chain acceptance): wolfSSL incorrectly accepts partial certificate chains, allowing an attacker to present a partial chain as fully trusted.
- CVE-2026-55960 (un-negotiated raw public key acceptance): wolfSSL accepts raw public keys that were never negotiated during the TLS handshake, opening a door for man-in-the-middle attacks.
Together, these flaws enable attackers to impersonate TLS servers and perform man-in-the-middle attacks against wolfSSL clients, potentially decrypting and manipulating communications that users believe to be secure.
Heap Buffer Overflows and Remote Code Execution Risk
Multiple vulnerabilities introduce heap buffer overflows and out-of-bounds writes that can be triggered before the remote peer is authenticated, making them particularly dangerous in server-facing deployments:
- CVE-2026-6679 and CVE-2026-5264: Crafted DTLS 1.3 ACK messages can overflow heap buffers, potentially enabling remote crashes or code execution on devices that support DTLS 1.3.
- CVE-2026-5295: PKCS7 ORI OID processing contains a stack overflow vulnerability affecting systems using CMS/SMIME or PKCS7-based secure messaging.
- Additional PKCS7 decode and decrypt bugs affect systems processing S/MIME or PKCS7-formatted messages.
Post-Quantum Cryptography Weaknesses
wolfSSL has been positioning itself as a post-quantum ready library, but several newly disclosed CVEs reveal serious implementation flaws in its ML-KEM and ML-DSA code paths:
- CVE-2026-5194: Missing digest size and OID validation in several signature algorithms allows signatures over shorter digests than permitted by FIPS standards, reducing the effective security of certificate-based authentication.
- Additional CVEs show that some ML-KEM code paths compare only portions of ciphertext or fail to enforce implicit rejection, weakening the IND-CCA2 security guarantees that are fundamental to post-quantum key encapsulation schemes.
Affected Products and Recommended Actions
Unpatched systems running vulnerable wolfSSL versions are exposed to certificate forgery, TLS identity bypass, heap corruption, padding-oracle decryption attacks, and various denial-of-service scenarios — particularly where DTLS 1.3, PKCS7, post-quantum cryptography, and OpenSSL compatibility APIs are enabled.
wolfSSL has released patched versions 5.9.1 and 5.9.2 that address the new CVEs. Administrators and IoT vendors should take the following actions:
- Upgrade to wolfSSL 5.9.1 or 5.9.2 immediately
- Disable optional features — such as OpenSSL compatibility mode, PKCS7, and experimental post-quantum support — where not strictly required
- Review and audit certificate validation logic in applications using wolfSSL’s OpenSSL-compatible APIs
- Rebuild firmware images for IoT and embedded devices with updated wolfSSL libraries
- Monitor for anomalous TLS and DTLS traffic targeting devices that expose wolfSSL-based services
IoT device manufacturers and vendors of embedded systems bear particular responsibility here: end users typically cannot update the TLS library embedded in a smart thermostat, industrial sensor, or automotive component. Manufacturers must push firmware updates proactively and communicate urgency to their customer base. Given the breadth of wolfSSL’s deployment, this disclosure represents a systemic risk that the security industry should treat with the same urgency as widely-exploited OpenSSL vulnerabilities in years past.