wolfSSL 5.9.4 Puts Trust State on the Patch Checklist

What does the release cover?

The High group concerns trusted-peer key matching (CVE-2026-93302), multiple OCSP stapling (CVE-2026-89102) and non-default Raw Public Key support (CVE-2026-89136). Each has its own prerequisites; the first two also depend on particular API use. The OCSP case can leave a certificate in a reused context’s trust store.

The Medium entries cover a conditional handshake flaw (CVE-2026-93304), name constraints (CVE-2026-89133, CVE-2026-89134) and shared certificate-manager contamination (CVE-2026-89135). The Low group covers shutdown use-after-free (CVE-2026-15442), combined OCSP/CRL checks (CVE-2026-94417), small-certificate verification with a permissive date callback (CVE-2026-94418) and legacy session references (CVE-2026-94419). Several paths can retain trust state after a connection ends.

Build an exposure decision around the application

BlackTree analysis: Start with the product owner, not a vulnerability score. Identify services and devices that ship wolfSSL, including statically linked copies. Record the linked library version, build settings and certificate-verification APIs from the actual deployed artefact. A package manifest that says “wolfSSL present” cannot tell you whether a conditional feature was compiled or used.

Split the review into three questions. Does the application authenticate a remote peer with the affected TLS or DTLS path? Does its build enable the relevant feature, such as trusted-peer certificates, multi-response OCSP, Raw Public Key, combined revocation checks or legacy session references? Does it reuse a certificate manager, TLS context or session cache across connections? Answering these in order avoids both a false all-clear from a default build assumption and a false alarm that every installation has every flaw.

Prioritise a service that accepts untrusted network peers and relies on the affected verification path. Give extra attention to a long-running service with shared trust state, because a clean handshake after patching does not itself show that old state has gone. If a prerequisite is absent, document how it was checked. If it is unknown, keep the item open for the maintainer or application team rather than silently treating it as absent.

Make the change prove two things

Deploy the fixed library or the product maintainer’s patched build. Confirm the application loads that build, then recreate any affected TLS contexts and restart long-running processes where old certificate or cache state could survive. wolfSSL says the fixed session-cache format rejects older persisted caches, but that is one cache path, not a substitute for checking other shared certificate managers.

BlackTree analysis: The acceptance test has two parts. First, verify the deployed binary and record the build flags and restart time. Second, exercise a negative authentication case matching the application’s actual configuration, such as a certificate outside an allowed name constraint or a revoked certificate where both OCSP and CRL checking are enabled. The expected result is a rejected handshake. A normal successful connection proves availability, not that the verification boundary is restored.

Keep the change record specific: affected product, owner, previous and fixed build, applicable feature, context lifetime and test result. If evidence later suggests a peer was wrongly trusted, those details tell responders whether to investigate a vulnerable handshake, retained state or an unrelated certificate problem. The vendor release reports fixes; it does not establish exploitation in any particular deployment.

Source

• wolfSSL, Release 5.9.4, heading dated 25 September 2026; GitHub release card dated 27 September 2026. Reviewed 30 September 2026.