Summary
- wolfSSL 5.9.4 addresses 11 CVEs: three high severity, four medium, and four low.
- High-severity issues affect trusted-peer certificates, multiple OCSP response stapling, and Raw Public Key authentication.
- Most affected scenarios depend on specific non-default build configurations or API use.
wolfSSL has released version 5.9.4 of its embedded TLS library with fixes for 11 vulnerabilities, including three high-severity weaknesses affecting certificate validation in particular configurations.
The company says the release addresses three high-severity, four medium-severity, and four low-severity CVEs. Most apply only to specific build configurations or API use, making configuration as important as the library version when assessing exposure.
The high-severity group affects trusted-peer certificate handling, client-side multiple OCSP response stapling, and Raw Public Key authentication.
CVE-2026-89136, for example, affects clients built with Raw Public Key support. An affected client can accept an unsolicited RawPublicKey server certificate type and bypass the authentication behaviour expected by the connection.
Raw Public Key support is disabled by default but can be enabled explicitly or through broad build configurations including --enable-all and --enable-distro.
The release also fixes medium-severity problems involving TLS and DTLS state handling and other certificate-processing behaviour, alongside lower-severity memory and protocol issues.
wolfSSL is designed for embedded and constrained systems as well as conventional software, which makes the remediation process different from updating a desktop application. The library can be compiled directly into firmware, network appliances, industrial devices, connected products, or vendor applications that customers cannot update independently.
That creates an inventory problem. An organisation may know it owns a particular device without knowing which wolfSSL version or build flags the manufacturer used when producing the firmware.
The vendor’s emphasis on configuration therefore matters. A vulnerability rated high in the underlying library does not mean every product containing wolfSSL is exposed. Equally, an affected feature can be buried inside equipment whose public documentation never identifies the TLS implementation.
Manufacturers will need to map the CVEs against their own build settings and issue downstream advisories where the affected code paths are present. Customers then depend on those suppliers to provide fixed firmware or confirm that vulnerable features were not compiled into the product.
Software bills of materials can help establish whether wolfSSL is present, but component identification alone may not resolve exposure where vulnerability status depends on compile-time options.
That distinction is increasingly relevant under European product-security regulation. Manufacturers are under growing pressure to understand the third-party components incorporated into products and maintain them through supported lifecycles rather than treating embedded libraries as invisible implementation details.
No broad exploitation campaign has been disclosed in connection with the 5.9.4 vulnerabilities. The immediate work is therefore dependency assessment rather than incident response.
For product suppliers, that means identifying whether the affected features were enabled. For customers, it can mean waiting for vendor-specific impact statements where the underlying library is too deeply embedded for direct inspection or independent patching.
