OpenSSL has released security updates for a high-severity weakness in its Datagram Transport Layer Security implementation that can expose process memory to a connected peer. The vulnerability, tracked as CVE-2026-84782, is an out-of-bounds read in the code responsible for retransmitting DTLS handshake messages. Depending on where the invalid read lands, an attack can either leak nearby heap contents as plaintext or terminate the affected process.

The defect matters because OpenSSL is embedded in far more than conventional web servers. VPN gateways, appliances, real-time communications software, embedded devices and custom applications may use DTLS when they need TLS-like protections over an unreliable datagram transport. Administrators therefore need to look beyond the OpenSSL package installed by the operating system.

How a suspended handshake causes the leak

DTLS must tolerate packets that arrive late, out of order or not at all. Its handshake logic can split large messages and retransmit earlier data when a timer expires. The vulnerable sequence begins when the transport cannot accept more output and OpenSSL pauses a partially completed handshake write with a WANT_WRITE result.

If a retransmission timer fires while that operation is suspended, affected versions reuse internal buffer and position information from the interrupted write. They do not reliably move the read position back to the start of the message that must be resent. As a result, a retransmission can begin from a stale offset, append bytes left from another message and continue beyond the intended allocation.

Those extra bytes may be sent to the peer as unencrypted handshake data. Their content depends on what happens to occupy adjacent heap memory, so there is no fixed secret that every exploit would reveal. Credentials, application data or cryptographic material could be nearby in some processes, while other attempts may encounter inaccessible memory and trigger a denial of service instead.

Every supported branch needs attention

The affected ranges are broad: OpenSSL 4.0 before 4.0.3, 3.6 before 3.6.5, 3.5 before 3.5.9, 3.4 before 3.4.8 and 3.0 before 3.0.23. Older premium-support branches are also affected before 1.1.1zj and 1.0.2zs. Fixes for those older lines are available only to eligible support customers.

The OpenSSL project corrected the problem by resetting the retransmission position and postponing retransmission while another handshake write remains paused. The vulnerable logic is outside the validated FIPS module boundary, so the FIPS module itself is not affected. That distinction does not make an application safe if its surrounding OpenSSL library still contains the faulty DTLS code.

What defenders should do now

• Inventory applications, VPN products, network appliances and embedded systems that expose or initiate DTLS sessions.
• Update maintained branches to 4.0.3, 3.6.5, 3.5.9 or 3.4.8, or install the vendor-provided package containing the equivalent fix.
• Check application directories, containers and firmware images for privately bundled libraries that the host package manager will not report.
• Review service crashes and unusual DTLS handshake behavior, while recognizing that a memory disclosure may leave limited evidence in ordinary logs.

The same security release also fixes 13 additional issues spanning certificate processing, QUIC, CMP, DTLS, SM2 and elliptic-curve operations. That makes the update a broader security maintenance event rather than a narrow response to one bug. Where immediate patching is impossible, teams should reduce unnecessary DTLS exposure and use network controls to limit who can reach affected services.

Laurent Gaffie of Secorizon reported the issue in August, and OpenSSL disclosed the correction on September 29. Coordinated patching is now essential. The technical details and affected-version information were reported by Cyber Security News.