OpenSSL patches a DTLS retransmission bug that leaks heap bytes in cleartext

17 August 2026. Laurent Gaffie, a researcher at Secorizon, reports an anomaly in OpenSSL’s DTLS retransmission logic. 29 September 2026. The project ships fixes and documents CVE-2026-84782, an out-of-bounds read (CWE-125) that CISA rates at CVSS 8.2. 29 September 2026. Ubuntu and Debian publish their patched packages the same day. Why it matters: DTLS is TLS for UDP traffic — it protects WebRTC data channels and the key negotiation of encrypted calls. A flaw that leaks memory bytes to the peer undermines the confidentiality of the very channel meant to guarantee it.

The flaw: a resend that starts from the wrong place

DTLS splits a large handshake message into fragments that each fit in a single UDP datagram. If the transport cannot accept more data at that moment, a write can suspend mid-message (the WANT_WRITE state) and resume later. While a write is suspended, the retransmission timer can fire independently and resend an earlier message already considered sent.

That is where the code was wrong. Before the fix, the retransmission reused the suspended message’s position instead of resetting to the start of the message being resent. The resent message went out with a mislabelled header, and its body was leftover bytes from the larger message still in flight. The read could then run past the end of the buffer.

Two consequences follow, per OpenSSL: the mislabelled message can carry heap memory to the peer as plaintext handshake data, or — if the read reaches unmapped memory — crash the program. The first leaks confidentiality, the second hands over a denial of service. CISA summarised the impact in the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H: confidentiality low, availability high, exploitation none at publication.

The flaw is not limited to client or server roles: OpenSSL tested the fix in both.

A quiet flaw with a wide surface

DTLS is not the protocol everyone thinks they know. It encrypts UDP traffic where classic TCP and TLS do not apply: WebRTC data channels, key setup for encrypted voice calls, some VPNs. An application is only exposed if it uses OpenSSL for DTLS — but that is more common than expected, because OpenSSL is often compiled statically or bundled into container images, firmware and desktop applications.

The distribution vendors’ wording exposes the severity gap. Ubuntu described the impact as “incorrect handshake behaviour or a denial of service”, without mentioning the memory leak. OpenSSL is more precise: the mislabelled message carries heap bytes “in cleartext”. This is not Heartbleed — the leak is not something an attacker can trigger on demand — but it depends on a synchronisation race, which makes it both hard to exploit and hard to dismiss.

The point is worth labouring because it changes the defensive posture. Heartbleed, in 2014, let an attacker ask for memory at will; here the leak is a side effect of a mispositioned resend. A defender cannot tell themselves “no public exploit, so no urgency”: the confidentiality is broken by construction, not by a proof of concept.

Which versions fix it — and which fix nothing

The fix is straightforward if you are on a supported branch.

• OpenSSL 4.0 → 4.0.3 — public download, supported until 14 May 2027
• OpenSSL 3.6 → 3.6.5 — public, until 1 November 2026
• OpenSSL 3.5 → 3.5.9 — public, LTS until 8 April 2030
• OpenSSL 3.4 → 3.4.8 — public, until 22 October 2026

The older branches are the real story. OpenSSL 3.0, 1.1.1 and 1.0.2 do get fixes — 3.0.23, 1.1.1zj, 1.0.2zs — but only for premium support customers. Public support for 3.0 ended on 7 September 2026, three weeks before this flaw. The 3.1, 3.2 and 3.3 branches were not checked.

OpenSSL lists no workaround for those who cannot update yet. Check your version, then the version of everything that links against the library:

openssl version
# 4.0.x  -> >= 4.0.3   |   3.6.x -> >= 3.6.5
# 3.5.x  -> >= 3.5.9   |   3.4.x -> >= 3.4.8

Ubuntu fixed the flaw on 29 September in its own packages, which keep older version numbers: 26.04 LTS (libssl3t64 3.5.5-1ubuntu3.6), 24.04 LTS (libssl3t64 3.0.13-0ubuntu3.16) and 22.04 LTS (libssl3 3.0.2-0ubuntu1.30), with a reboot required. Debian published DSA-6531-1 for Debian 13 (package 3.5.7-1~deb13u3).

What an SRE should do right now

The priority is not patching one server; it is finding every copy of OpenSSL you run without knowing it.

• Inventory embedded binaries. A container image that compiles OpenSSL statically will not be fixed by the host package. trivy, grype or docker scout must surface CVE-2026-84782 if your vulnerability databases are current.
• Treat dead branches as risk, not legacy. A server on OpenSSL 3.0 without a premium contract will not get this fix. Migrate to 3.5 LTS rather than hand-rolling a rebuild.
• Do not stop at the system package version. The host libssl can be current while an embedded Python, Node or Go application runs on a vulnerable copy. Static bundling is the classic blind spot.
• Watch DTLS retransmission if you expose it. A spike in handshake errors or crashes from a WebRTC service deserves a look, even without proof of exploitation.

The thing to internalise is that the leak is silent. A resend that exposes sixteen heap bytes triggers no alert; closing the channel takes a patch, not detection.

Verdict

If you run OpenSSL 3.4, 3.5, 3.6 or 4.0, update now — the fix is public, tested in both roles, and the High severity means OpenSSL’s own policy calls for applying it “as soon as possible”. If you are still on 3.0, 1.1.1 or 1.0.2 without premium support, you are effectively out of fixes: schedule the migration to 3.5 LTS as a security project, not a maintenance chore. If you operate WebRTC or encrypted telephony services, treat CVE-2026-84782 as a potential confidentiality leak and force the update across the whole chain, down to the container images.

References

• The Hacker News — OpenSSL Fixes High-Severity DTLS Flaw That Can Leak Heap Memory Unencrypted
• NVD — CVE-2026-84782
• OpenSSL — Security advisories