.png?w=1024)
A flaw in OpenSSL’s DTLS handshake handling could send fragments of an application’s memory to the other end of a connection.
OpenSSL disclosed and patched the high-severity vulnerability, tracked as CVE-2026-84782, on September 29. Its security advisory says the bug can expose heap memory as plaintext handshake data or crash an affected process, causing a denial of service.
For security teams, the first question is which applications use OpenSSL’s Datagram Transport Layer Security (DTLS), a protocol that secures datagram traffic, typically over UDP. The flaw occurs when OpenSSL retransmits a handshake message while another handshake write is suspended, so teams need to check how their applications use DTLS.
How the DTLS flaw exposes memory
The problem occurs when a handshake message is only partly written because the underlying transport temporarily cannot accept more data. If a retransmission timer fires while that write is suspended, OpenSSL can resend an earlier message using the wrong position in a shared buffer.
That stale position can cause the retransmission to include unintended bytes and read beyond the allocated buffer. Those bytes may reach the peer unencrypted; reading into an unmapped memory region can instead crash the process.
The advisory also describes a separate failure in which retransmission overwrites bookkeeping needed to resume the suspended write. Resuming it can abort the process in a debugging build. The patch corrects the retransmission position and defers retransmission while a handshake write remains suspended.
OpenSSL previously addressed vulnerabilities that could enable remote code execution in January. The documented impacts of this DTLS flaw are memory disclosure and denial of service; the advisory does not identify remote code execution as an outcome.
Which OpenSSL versions need updates?
OpenSSL’s advisory lists the following upgrade targets for affected branches:
OpenSSL branch | Fixed version |
|---|---|
4.0 | 4.0.3 |
3.6 | 3.6.5 |
3.5 | 3.5.9 |
3.4 | 3.4.8 |
3.0 | 3.0.23 |
1.1.1 | 1.1.1zj |
1.0.2 | 1.0.2zs |
The advisory places the fixes for 3.0, 1.1.1, and 1.0.2 under premium support.
Organizations using distribution packages should check their distributor’s security notice rather than judge patch status solely by the upstream version number. Ubuntu, for example, lists fixes in packages including 3.0.13-0ubuntu3.16 for Ubuntu 24.04 LTS and 3.0.2-0ubuntu1.30 for Ubuntu 22.04 LTS.
What security teams should do now
A practical response starts with identifying applications that use affected OpenSSL versions and determining whether they use DTLS. Include vendor-managed products and applications with embedded library copies when asking suppliers about exposure and available updates.
Teams can use vulnerability management tools to support discovery and remediation tracking, then confirm application-specific exposure with developers or vendors. A library finding is a starting point for investigation.
Apply the appropriate upstream, distribution, or vendor update, test affected services, and verify that deployment succeeded. Those checks belong in a repeatable patch management process that covers inventory, prioritization, testing, and post-update validation.
The takeaway for defenders is concrete: establish where affected DTLS code is used, assign an owner to each update, and confirm that the application is running the patched library.
Read more: Learn how a critical GitLab GraphQL flaw could expose public repositories to deletion and tampering.