OpenSSL DTLS Retransmission Bug Can Leak Heap Data or Terminate Applications

OpenSSL CVE-2026-84782 DTLS flaw can leak heap memory or crash apps. See affected versions, fixes, Ubuntu and Debian patches.

OpenSSL DTLS Retransmission Bug Can Leak Heap Data or Terminate Applications
Vulnerabilities

Illustrative image generated with AI

Listen to this articleAudio edition · 10 min

Faulty retransmissions create two distinct risks

OpenSSL has disclosed a high-severity flaw in its Datagram Transport Layer Security implementation that can expose heap memory to a remote peer or crash the affected process.

Tracked as CVE-2026-84782, the vulnerability affects DTLS handshake-message retransmissions. OpenSSL released corrections on September 29 and rated the issue High, one level below Critical on its severity scale.

Laurent Gaffie of Secorizon reported the vulnerability on August 17. Ryan Hooper developed the fix.

CISA assigned CVE-2026-84782 a CVSS score of 8.2 out of 10 on September 29, using the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H. That assessment describes a network-accessible flaw requiring neither privileges nor user interaction, with low confidentiality impact and high availability impact.

OpenSSL does not use CVSS scores to determine its own severity classifications and cautions that external scoring may differ substantially from its assessments.

At the time of CISA’s record, exploitation was marked as “none.” OpenSSL had not reported attacks, and no CISA Known Exploited Vulnerabilities remediation deadline was specified.

How a paused DTLS handshake exposes the wrong memory

DTLS adapts TLS protections to datagram-based transport such as UDP. It can be used to secure WebRTC data channels and help establish encryption keys for internet calls.

Large DTLS handshake messages must be divided into fragments that fit within individual UDP datagrams. If a connection temporarily stops accepting additional data, OpenSSL can pause while part-way through sending one of those messages.

A retransmission timer may expire during that pause. OpenSSL must then resend an earlier handshake message, but the vulnerable code can begin from the current buffer position of the paused, larger message instead of the start of the message selected for retransmission.

This state mismatch produces malformed handshake data. The retransmitted message receives the wrong label and may contain residual bytes belonging to the larger buffered message.

Processing the malformed data can then read past the intended buffer boundary. According to OpenSSL, heap contents may be sent to the peer as unencrypted handshake data. If the out-of-bounds read crosses into unmapped memory, the application can terminate.

That creates two possible outcomes: limited disclosure of process memory and denial of service. Ubuntu’s USN-8847-1 advisory describes incorrect handshake behavior and denial of service but does not mention the heap-memory exposure identified by OpenSSL.

The exposure is not confined to either DTLS clients or servers. OpenSSL tested its correction in both roles. However, it has not stated whether an attacker can reliably force a retransmission at the precise moment that another handshake message is paused.

Fixed versions leave unsupported branches with limited options

Every release preceding the following fixed version in each listed branch is affected:

OpenSSL branch Fixed version Distribution and support status
4.0 4.0.3 Publicly available; supported until May 14, 2027
3.6 3.6.5 Publicly available; supported until November 1, 2026
3.5 3.5.9 Publicly available LTS release; supported until April 8, 2030
3.4 3.4.8 Publicly available; supported until October 22, 2026
3.0 3.0.23 Available only to premium-support customers; public support ended September 7, 2026
1.1.1 1.1.1zj Premium-support customers only; no public support
1.0.2 1.0.2zs Premium-support customers only; no public support

OpenSSL did not determine whether branches 3.1, 3.2, and 3.3 are affected. Those branches no longer receive public support.

The position of OpenSSL 3.0 is particularly significant for organizations that compile the library themselves or embed it into other products. Its final public release was 3.0.22, published on August 25. Version 3.0.23 is the first security update in that branch withheld from public distribution by OpenSSL.

That premium-only update addresses six of the 14 vulnerabilities corrected on September 29, including CVE-2026-84782. Organizations remaining on upstream OpenSSL 3.0 therefore cannot obtain the official public fix for this vulnerability.

OpenSSL recommends migrating to a supported branch, including 4.0 or the long-term-support 3.5 line, or purchasing support. No workaround has been published for environments unable to update.

Ubuntu and Debian distribute backported corrections

Linux distribution package versions do not necessarily match the fixed upstream release numbers because maintainers often backport security patches.

Ubuntu Security published USN-8847-1 on September 29, 2026, covering Ubuntu 26.04 LTS, 24.04 LTS, and 22.04 LTS. The corrected packages are:

Ubuntu release Package Corrected package version
26.04 LTS (resolute) libssl3t64 3.5.5-1ubuntu3.6
24.04 LTS (noble) libssl3t64 3.0.13-0ubuntu3.16
22.04 LTS (jammy) libssl3 3.0.2-0ubuntu1.30

Ubuntu users should perform a standard system update and then reboot so that every running service and process loads the corrected libraries. Merely installing the package may leave long-running applications using the vulnerable code already mapped into memory.

Ubuntu Pro offers ten years of security coverage for more than 25,000 packages in the Main and Universe repositories. It is available without charge for up to five machines.

Debian corrected CVE-2026-84782 in Debian 13 through openssl package version 3.5.7-1~deb13u3, released under DSA-6531-1. At 07:36 UTC on September 30, Debian’s security tracker still identified Debian 12 as vulnerable.

Administrators should inventory DTLS use, not just OpenSSL installations

The flaw is relevant only where software uses OpenSSL’s DTLS implementation. An installed OpenSSL package alone does not establish that an application exercises the vulnerable path.

Defenders should identify internet-facing and internally exposed services using DTLS, including communications software and WebRTC-related components. They should also examine appliances, containers, statically linked programs, and vendor products that may bundle their own OpenSSL copies rather than using the operating system package.

Priority should go to remotely reachable applications where a crash would interrupt real-time communications or another availability-sensitive service. Heap disclosure is also possible, although neither the type nor amount of memory obtainable in practice has been established.

No specific indicators of compromise have been published. Unexplained crashes during DTLS handshakes, malformed retransmitted handshake messages, and repeated connection failures may justify investigation, but they are not confirmed evidence of exploitation.

The same release fixes 13 additional vulnerabilities

The September 29 updates addressed 13 other OpenSSL flaws. The most serious identified alongside CVE-2026-84782 is CVE-2026-84783, a Moderate-severity issue limited to OpenSSL 4.0.

A remote, unauthenticated peer can exploit that flaw to crash certain multithreaded TLS clients or servers requesting client certificates. The condition requires several connections to build their first certificate chains to the same trusted CA certificate simultaneously. Its CVSS score is 7.5, with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

CVE-2026-75806, rated Low by OpenSSL and scored 5.3, allows an attacker to terminate an established DTLS 1.2 connection using an AEAD cipher suite. A single undersized datagram can trigger the failure without knowledge of the connection’s keys.

The remaining Low-severity findings include five problems in OpenSSL’s QUIC implementation and three timing side channels affecting ECDSA or SM2 operations. Ubuntu also documented denial-of-service, out-of-bounds-read, excessive-memory-consumption, and certificate-processing defects among the bundled corrections.

Organizations applying the CVE-2026-84782 fix should therefore deploy the complete vendor update rather than attempting to isolate one patch. The release closes a broader set of network-facing failure modes at the same time.

Read next

Sources

This article is an original reworking based on the sources below.

CVEs covered in this article

Back to home

Latest Cybersecurity News

All cybersecurity news →