wolfSSL 5.9.4 makes a simple “version updated” sign-off inadequate. Its vendor notes list 11 vulnerabilities: three High, four Medium and four Low. The release heading says 25 September; GitHub shows publication on 27 September. Exposure depends on the deployed application's build and behaviour. 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…