Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

OpenSSL Patches High-Severity DTLS Flaw That Can Leak Heap Memory

A stalled handshake retransmission in OpenSSL's DTLS code could hand an attacker unencrypted heap memory from the other side of the connection, or crash the process outright. Patches are out — here's who's affected and what to do.

4T4Tify Team4Tify
Sep 30, 2026·5 min read
OpenSSL Patches High-Severity DTLS Flaw That Can Leak Heap Memory

OpenSSL Patches High-Severity DTLS Flaw That Can Leak Heap Memory

OpenSSL has released fixes for a high-severity vulnerability in its DTLS implementation, tracked as CVE-2026-84782, that can expose unencrypted heap memory to the other end of a connection — or crash the affected process. The flaw sits one step below OpenSSL's top severity rating and touches both DTLS clients and servers.

What Happened

DTLS is the UDP variant of TLS, commonly used to protect VoIP calls and WebRTC data channels. Because large handshake messages don't fit in a single UDP datagram, DTLS splits them into fragments. If the connection can't accept more data mid-transfer, sending pauses partway through a message and resumes later — and if a retransmission timer fires while that pause is in effect, OpenSSL resends an earlier handshake message.

The bug: that resend used the buffer position of the paused message instead of returning to the start of the message actually being retransmitted. The result was a mislabeled handshake message whose body was built from leftover bytes of the larger, in-progress message — and reading it could run past the end of the buffer. In practice, that mislabeled message could carry unencrypted heap memory from one party across to the other, or trigger a crash if it strayed into unmapped memory.

The issue was reported by security researcher Laurent Gaffie and fixed by OpenSSL contributor Ryan Hooper. OpenSSL says it has no evidence of active exploitation, and CISA's independent scoring (6.2/10) rated confidentiality impact as low and availability impact as high — though OpenSSL notes its own severity ratings and third-party CVSS scores can diverge significantly.

Why It Matters

Anything terminating DTLS — VoIP infrastructure, WebRTC gateways, IoT and embedded stacks, VPNs that tunnel over DTLS — is a candidate for exposure until patched. The fix landed in OpenSSL 4.0.3, 3.6.5, 3.5.9 and 3.4.8, all available as free downloads. Older branches (3.0, 1.1.1, 1.0.2) only receive the fix under a paid premium-support contract; OpenSSL 3.0's free public support ended on September 7, and this is the first 3.0 security release OpenSSL has not made public.

That creates a real gap: organizations running OpenSSL 3.0 without a support contract, or vendors who bundle their own copy of OpenSSL 3.0 inside a product, have no official public fix. Downstream distributions have started closing that gap independently — Ubuntu shipped updated packages for 22.04, 24.04 and 26.04 on September 29, and Debian 13 received a fix the same week, though Debian 12 remained listed as vulnerable as of press time.

The same release also fixed 13 other OpenSSL flaws, including a Moderate-severity crash bug in multi-threaded TLS 4.0 deployments and several Low-severity issues in QUIC and ECDSA/SM2 timing side-channels.

What To Do

  • Inventory your DTLS exposure. Identify every service terminating DTLS — VoIP/WebRTC gateways, VPN concentrators, embedded and IoT devices — and confirm which OpenSSL branch and version each one runs.
  • Patch to a fixed version. Upgrade to 4.0.3, 3.6.5, 3.5.9 or 3.4.8 depending on your branch. If you're on 3.0, 1.1.1 or 1.0.2 without a support contract, plan a migration to a currently supported branch (3.5 LTS or 4.0) rather than waiting on a fix that won't come publicly.
  • Apply distro updates promptly. If you rely on OS-packaged OpenSSL, apply your distribution's latest security update and reboot affected hosts — package version numbers may not match upstream OpenSSL's.
  • Don't assume low likelihood means low priority. No exploitation has been observed, but a memory-disclosure bug reachable by any DTLS peer is worth prioritizing in your next patch cycle rather than deferring to a routine maintenance window.
SHARE