High-Severity Vulnerabilities Patched in OpenSSL, WolfSSL

OpenSSL and WolfSSL Ship Fixes for Roughly Two Dozen Combined Flaws

The OpenSSL and wolfSSL projects each released security updates in the last week of September 2026, together resolving roughly 25 vulnerabilities across the two widely embedded cryptographic libraries. OpenSSL patched 14 flaws, including one high-severity out-of-bounds read in its DTLS (Datagram TLS) handshake-retransmission logic — tracked as CVE-2026-84782 (CVSS 8.2) — that can leak fragments of heap memory to a remote, unauthenticated peer or crash the affected application. wolfSSL released version 5.9.4 on September 25, 2026, fixing 11 vulnerabilities, three of them high severity, including flaws that let an attacker forge TLS certificates for arbitrary identities or bypass server authentication entirely under certain configurations. Both libraries are embedded across an enormous range of products — VPNs, VoIP systems, IoT devices, embedded/edge hardware, and server software including Nginx, HAProxy, Stunnel, and Apache httpd — making the practical patching footprint of this release wave large even though neither project has confirmed active exploitation.

Details

What Was Fixed in OpenSSL

OpenSSL's high-severity fix, CVE-2026-84782, addresses a bug the project titled "DTLS Retransmits Handshake Messages From a Stale Buffer Offset." When a DTLS handshake message write is suspended partway through and then retransmitted, the retransmission logic can read past the message buffer and overwrite internal state the original, suspended write needs to resume correctly. The result is that a remote peer can trigger an out-of-bounds read, potentially leaking fragments of heap memory back over the connection, or crash the application outright. Because the flaw sits in DTLS — the datagram variant of TLS used heavily in VPNs, VoIP, and IoT deployments — and can be triggered remotely without authentication in either the client or server role, OpenSSL rated it High, one tier below Critical on its severity scale. The vulnerable code lies outside the boundary of the OpenSSL FIPS module, so FIPS-validated builds are not affected by this specific issue.

A second, medium-severity flaw, CVE-2026-84783, enables a remote denial-of-service condition against multi-threaded TLS clients. The remaining dozen low-severity fixes cover a mix of resource-exhaustion DoS, process crashes, premature DTLS 1.2 connection termination, QUIC DDoS-amplification abuse, and timing side-channel weaknesses that could theoretically assist key recovery. OpenSSL published fixed releases across every actively supported branch: 4.0.3 (current), 3.6.5 (supported until November 1, 2026), 3.5.9 (long-term support, supported until April 8, 2030), 3.4.8 (supported until October 22, 2026), and 3.0.23. Fixes for the legacy 1.1.1 and 1.0.2 branches are available only to organizations paying for OpenSSL's premium/extended support program.

What Was Fixed in WolfSSL

wolfSSL 5.9.4, released September 25, 2026, patches 11 vulnerabilities and adds a batch of new cryptographic and performance features, including a native Falcon post-quantum signature implementation, FrodoKEM with assembly optimizations, SLH-DSA (FIPS 205) support for TLS 1.3/DTLS 1.3, Argon2 password hashing (RFC 9106), and AES-GCM-SIV (RFC 8452).

The three high-severity flaws are all certificate/authentication bypass issues:

• CVE-2026-93302 — MatchTrustedPeer ignored the public key when matching a certificate against a trusted peer certificate, allowing a malicious (D)TLS server to bypass authentication once it knows which CAs the client trusts. Affects versions 5.3.0–5.9.2 under specific build macros, and is noted as particularly relevant to trusted-peer certificate APIs used by Nginx, HAProxy, Stunnel, and Apache httpd integrations.
• CVE-2026-89102 (CVSS 8.3) — A client-side flaw in multi-response OCSP stapling (RFC 6961) handling, present when an application enables HAVE_CERTIFICATE_STATUS_REQUEST_V2 and calls wolfSSL_UseOCSPStaplingV2 with multi-response options. Affected clients accept any certificate in a peer's chain as a certificate authority without verifying it is actually authorized to act as one, letting an attacker who holds any certificate chaining to a client-trusted CA forge certificates for arbitrary identities. The unverified end-entity certificate is also cached in the persistent trust store, affecting later connections that reuse the same context. Affects versions 5.7.2–5.9.2; found through internal wolfSSL testing rather than external report.
• CVE-2026-89136 — Clients with Raw Public Key (RPK) support enabled accept an unsolicited server certificate type the client never requested, letting a malicious or misbehaving server bypass client-side authentication. Affects versions 5.6.0–5.9.2 in RPK-enabled builds.

Four medium-severity flaws were also fixed: CVE-2026-93304 (TLS 1.2 clients could accept an out-of-order ChangeCipherSpec message, letting an attacker complete a handshake in the server's place), CVE-2026-89133 (an unconstrained intermediate CA in a certificate chain could reset NameConstraints validation state, potentially allowing certificates for unauthorized hostnames), CVE-2026-89134 (a non-DNS Subject Alternative Name in a certificate could let an out-of-scope Common Name bypass DNS NameConstraints checks), and CVE-2026-89135 (a failed X509_verify_cert call could permanently cache an unverified attacker-controlled CA in the shared CertManager, silently bypassing validation for every other consumer of that manager — native TLS, OCSP, CRL, and direct CM verification calls alike — affecting versions 5.8.4–5.9.2).

Four low-severity issues round out the release: CVE-2026-15442 (a heap use-after-free during TLS shutdown under certain conditional states, affecting versions 4.4.0–5.9.2), CVE-2026-94417 (when both OCSP and CRL checking are enabled, a missing OCSP responder could cause acceptance of a certificate the loaded CRL had already listed as revoked), CVE-2026-94418 (inverted certificate-signature verification precedence under the WOLFSSL_SMALL_CERT_VERIFY build option), and CVE-2026-94419 (TLS 1.2 session-cache confusion via server-chosen session IDs, enabling server impersonation in resumed sessions).

Why This Matters

Recommendations

For developers and DevOps teams

• Identify every build that statically links or vendors OpenSSL or wolfSSL, not just system-level package installs — CVE fixes only help once the binary is rebuilt or the shared library is replaced.
• Upgrade OpenSSL to the fixed release matching your branch: 4.0.3, 3.6.5, 3.5.9, 3.4.8, or 3.0.23.
• Upgrade wolfSSL to 5.9.4 or later, prioritizing systems that use trusted-peer certificate APIs, multi-response OCSP stapling, Raw Public Key support, OpenSSL compatibility APIs, combined OCSP+CRL checking, or legacy TLS 1.2 session resumption — the feature areas touched by the high- and medium-severity fixes.

For infrastructure and security teams

• Prioritize systems that terminate DTLS traffic (VPN concentrators, VoIP/SIP gateways, IoT/edge devices) for the OpenSSL update, given CVE-2026-84782's remote, unauthenticated trigger.
• Audit reverse proxies and load balancers — Nginx, HAProxy, Stunnel, Apache httpd — for embedded or system wolfSSL versions, since several of the high-severity CVEs specifically call out these integrations.
• Check vendor advisories for embedded/IoT and network appliances; downstream distribution fixes typically lag the upstream release, so confirm your Linux distribution or device vendor has actually shipped the patched package rather than assuming an OS-level update covers it.
• Where DTLS, OCSP stapling, or Raw Public Key features aren't actively required, consider disabling them as a temporary mitigation on systems that can't be patched immediately.

For asset owners running embedded/IoT devices

• Inventory devices — routers, cameras, industrial controllers, VoIP phones — that may embed either library in firmware, since these are often the slowest to receive updates.
• Apply firmware updates from device vendors as they become available, and monitor vendor security bulletins referencing OpenSSL 4.0.3/3.6.5/3.5.9/3.4.8 or wolfSSL 5.9.4.

Key Takeaways

1. OpenSSL and wolfSSL together fixed roughly 25 vulnerabilities in security releases issued the same week in late September 2026.
2. OpenSSL's standout flaw, CVE-2026-84782 (CVSS 8.2), is a remote, unauthenticated out-of-bounds read in DTLS handshake retransmission that can leak heap memory or crash affected applications; fixed in 4.0.3, 3.6.5, 3.5.9, 3.4.8, and 3.0.23.
3. wolfSSL 5.9.4 (released September 25, 2026) fixed 11 flaws, including three high-severity certificate-forgery and authentication-bypass issues — CVE-2026-93302, CVE-2026-89102 (CVSS 8.3), and CVE-2026-89136.
4. The wolfSSL flaws specifically threaten deployments using trusted-peer certificate matching, multi-response OCSP stapling, and Raw Public Key TLS — features found in proxies like Nginx, HAProxy, Stunnel, and Apache httpd.
5. Neither project has confirmed active exploitation, but both libraries' broad embedding in VPNs, VoIP, IoT, and server software means real-world patch rollout will lag well behind the release date.
6. Organizations should inventory every product that vendors or statically links OpenSSL or wolfSSL — not just OS-level packages — to close the gap between "patch available" and "patch deployed."

Sources

• High-Severity Vulnerabilities Patched in OpenSSL, WolfSSL — SecurityWeek
• OpenSSL Fixes High-Severity DTLS Flaw That Can Leak Heap Memory — The Hacker News
• wolfSSL 5.9.4 Patches 11 Security Flaws Affecting TLS and Certificate Validation — GBHackers
• wolfSSL Release 5.9.4 (September 25, 2026) — GitHub