Security4 publishers2 min readPublished
OpenSSL patches a DTLS flaw that sends heap memory to unauthenticated peers
OpenSSL patched 14 flaws, led by CVE-2026-84782, a CVSS 8.2 DTLS handshake bug that lets an unauthenticated remote peer pull fragments of heap memory. Only software that speaks DTLS is exposed, so VPN, VoIP and IoT products go first in the patch queue.
The Watch · Security desk
What happened
- The bug fires when OpenSSL retransmits a handshake message while sending another is stalled, and leftover heap data then goes to the other party in plaintext.
- If that read runs into unmapped memory, the application crashes instead, leaving a denial-of-service condition.
- A second OpenSSL flaw, the medium-severity CVE-2026-84783, lets a remote unauthenticated peer crash a multi-threaded TLS client.
- WolfSSL shipped version 5.9.4 on September 25 with fixes for 11 vulnerabilities, three of them rated high severity.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision Patch order can follow protocol use. DTLS-speaking VPN, VoIP and IoT systems go ahead of TLS-only OpenSSL deployments, since only DTLS reaches the high-severity bug.
- exposure Any service answering DTLS handshakes from untrusted networks can have heap memory read or be crashed by a peer holding no credentials.
- decision Mixed stacks cannot be ranked on the OpenSSL score alone. A WolfSSL client that accepts a forged CA clone lets a malicious server pass as authentic, so those fixes belong in the same patch window.
According to SecurityWeek, the flaw can be exploited over the network with no authentication and no user interaction [5]. The harder requirement is timing, and how reliably a hostile peer can force it decides whether the bug works against every exposed endpoint. OpenSSL has to be retransmitting one handshake message while sending another is stalled [3].
The scope is narrow and easy to check. The flaw is in the DTLS handshake, so an OpenSSL application serving only TLS over TCP is outside CVE-2026-84782 [2]. DTLS is common in VPNs, VoIP and IoT products [2], and those go first.
Most of the 12 low-severity OpenSSL fixes [1] end in denial of service through memory or CPU exhaustion, process crashes, or terminated DTLS 1.2 connections [7]. The terminated-connection bugs hit the same DTLS deployments [7]. The rest let attackers abuse QUIC servers for DDoS amplification or use timing side channels that could lead to private key recovery [8].
WolfSSL's high-severity fixes deal with a different attacker: a malicious server that gets past peer authentication in certain configurations [10]. In CVE-2026-93302, WolfSSL ignores the public key when it matches a certificate against a trusted peer certificate [11]. A server that knows which CAs a client trusts can present a forged clone of one and bypass authentication [11]. Builds made for Nginx, HAProxy, Stunnel and Apache httpd are among those affected [12].
CVE-2026-89102 lets anyone holding a certificate and private key that chain to a trusted CA forge certificates for arbitrary identities [13]. CVE-2026-89136 hits clients with Raw Public Key support enabled. The malicious server selects an RPK certificate type the client never requested [14].
The four medium-severity WolfSSL bugs include a handshake sequencing error. Between them, they can let an attacker complete a TLS 1.2 or DTLS 1.2 handshake in place of the legitimate server [15]. Most of the four low-severity bugs need specific configurations or legacy API usage [16].
SecurityWeek's report does not list fixed OpenSSL version numbers or describe exploitation in the wild for any of the 25 fixes across both libraries [3].
What to watch
- Published detail from OpenSSL or researchers on how reliably a peer can force the stalled-send retransmission state behind CVE-2026-84782.
- Advisories and fixed firmware from VPN, VoIP and IoT vendors whose DTLS stacks are built on OpenSSL.
- Any report of CVE-2026-84782 or the WolfSSL authentication bypasses being exploited in the wild.