OpenSSL and WolfSSL patch high-severity TLS flaws
The maintainers of two widely used open source cryptographic libraries, OpenSSL and WolfSSL, have each released fixes for about a dozen security issues. Both batches include flaws rated high severity. In WolfSSL's case, three of them can let attackers get around peer authentication.
OpenSSL fixes DTLS memory leak
OpenSSL patched 14 vulnerabilities. Only one is rated high severity. It is tracked as CVE-2026-84782 and affects applications that use Datagram TLS (DTLS). DTLS is a variant of TLS built for connectionless traffic, and it often appears in VPNs, VoIP systems and IoT devices.
The bug is triggered during the DTLS handshake. If OpenSSL retransmits a message while sending another message is stalled, leftover heap data can be sent to the remote party in plaintext. A remote peer can use this to obtain fragments of heap memory. If the read reaches unmapped memory, the application crashes, which creates a denial-of-service (DoS) condition.
The flaw has a CVSS score of 8.2. It can be exploited over the network with no authentication and no user interaction.
The releases also address a medium-severity issue, CVE-2026-84783. A remote, unauthenticated peer can use it to crash a multi-threaded TLS client, again resulting in DoS.
The remaining OpenSSL bugs are rated low severity. Most of them cause DoS conditions through excessive memory or CPU consumption, process crashes, or the termination of DTLS 1.2 connections. Two other kinds of issue stand out. Some could let attackers abuse QUIC servers for DDoS amplification. Others involve timing side channels that could leak information useful for recovering private keys.
WolfSSL 5.9.4 closes authentication bypasses
WolfSSL shipped version 5.9.4 on September 25. Alongside new features, the release fixes 11 vulnerabilities, and three of them are rated high severity. Each of the three can let an attacker bypass peer authentication in certain configurations.
CVE-2026-93302 exists because WolfSSL does not check the public key when it matches a certificate against a trusted peer certificate. A malicious server that knows which certificate authorities (CAs) a client trusts can present a forged clone of one of those CAs and get past authentication. Affected builds include those made for integration with Nginx, HAProxy, Stunnel, Apache httpd and other applications.
CVE-2026-89102 works from a different starting point. An attacker who holds any certificate, along with its private key, that chains to a CA trusted by the client can forge certificates for arbitrary identities.
CVE-2026-89136 affects clients that have Raw Public Key (RPK) support enabled. A malicious server can bypass authentication by selecting an RPK certificate type that the client never asked for.
Four medium-severity bugs relate to certificate validation defects and a handshake sequencing error. An attacker could use them to bypass name constraints or plant an unverified CA in the shared certificate manager. The handshake error could let an attacker complete a TLS 1.2 or DTLS 1.2 handshake in place of the legitimate server and send data that the client accepts as authentic.
The four low-severity issues could cause:
- a use-after-free during connection shutdown
- skipped CRL revocation checks
- acceptance of certificates with invalid signatures
- server impersonation
Most of these require specific configurations or legacy API usage.
Why It Matters
The two libraries are exposed in different ways. The high-severity OpenSSL flaw leaks memory and crashes services. The WolfSSL flaws go after the trust model itself, letting a malicious server pass as legitimate. For a TLS library, authentication bypasses are arguably the more serious category, because they undermine the guarantee that users rely on the library to provide.
The DTLS angle is worth attention. DTLS is common in VPNs and IoT gear, and those products are often patched slowly. Edge devices continue to draw attackers, as recent exploitation of VPN appliances shows. WolfSSL is popular in embedded products, so fixes may take a while to reach end users through vendor firmware.
The OpenSSL timing side-channel bugs are rated low. Still, they fit a steady stream of research into leakage through timing and hardware behaviour, such as the recent Spectre v2 variant.
Several things are worth watching. One is whether downstream vendors that bundle these libraries issue their own advisories. Another is whether proof-of-concept code surfaces for the WolfSSL authentication bypasses. Teams using the Nginx, HAProxy, Stunnel or Apache httpd integrations should check their builds first.