CVE-2026-84782 can leak heap memory to the other side of a DTLS connection or crash the program, OpenSSL said on September 29 as it released fixes.
CVE-2026-84782: the bug and how it leaks data
OpenSSL described a defect in its DTLS implementation that can cause a resent handshake message to be assembled and labeled incorrectly. DTLS fragments large handshake messages into UDP-sized datagrams; if a large handshake is part-way through sending and the connection cannot accept more data, sending can pause and continue later. While that send is paused, DTLS's resend timer can still fire and retransmit an earlier handshake message.
Before the September 29 fixes, the resend used the paused message's current position in the buffer instead of restarting from the beginning of the message being resent. The retransmitted record therefore carried the wrong label and a body composed of leftover bytes from the larger, paused message. Reading that wrongly labeled record could overrun the buffer, potentially sending heap memory to the remote peer as unencrypted handshake data. If the read reached unmapped memory, the program could crash.
OpenSSL does not restrict the flaw to clients or servers and said it tested the fix in both roles. The project also said it has not reported any attacks exploiting the flaw, and it has not said whether an attacker can cause the resend condition while a message is stuck.
Which OpenSSL releases fix the flaw and distribution updates
OpenSSL released official fixes in these public builds: 4.0.3, 3.6.5, 3.5.9 and 3.4.8. The project noted that fixes for older branches — 3.0, 1.1.1 and 1.0.2 — are available only to paying customers with OpenSSL's premium support, and that OpenSSL 3.0 stopped receiving public security fixes on September 7.
Distributors issued their own packages. Ubuntu published fixes on September 29 that keep older OpenSSL version numbers:
- Ubuntu 26.04 LTS: libssl3t64 3.5.5-1ubuntu3.6
- Ubuntu 24.04 LTS: libssl3t64 3.0.13-0ubuntu3.16
- Ubuntu 22.04 LTS: libssl3 3.0.2-0ubuntu1.30
Ubuntu's notice instructs users to reboot after the update for all changes to take effect. Debian fixed the flaw in Debian 13 with openssl version 3.5.7-1~deb13u3 (DSA-6531-1); Debian's security tracker still listed Debian 12 as vulnerable as of 07:36 UTC on September 30.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildSeverity, related fixes, and vendor ratings
OpenSSL rated CVE-2026-84782 High, one step below Critical on its internal severity scale, and advised installing High fixes as soon as possible. The Cybersecurity and Infrastructure Security Agency (CISA) assigned the flaw a CVSS score of 8.2 out of 10 on September 29, rating confidentiality impact Low and availability impact High, and listing exploitation as "none" at that time. OpenSSL noted that it does not use CVSS to set its severity ratings and that outside scores can differ greatly from its own.
The September 29 releases addressed 14 flaws in total; in addition to CVE-2026-84782, OpenSSL fixed 13 other issues. The most serious among those was CVE-2026-84783, rated Moderate and affecting only OpenSSL 4.0: a remote, unauthenticated peer could crash a multi-threaded TLS client or a multi-threaded TLS server that requests client certificates, but only in a narrow condition when several connections build their first certificate chains to the same trusted CA at the same time. Another DTLS issue, CVE-2026-75806 (Low), could let anyone able to send a datagram to an established DTLS 1.2 AEAD connection end that connection with a single too-short datagram without knowing keys. OpenSSL also fixed five QUIC issues and three timing side-channels in ECDSA and SM2, among other Low-rated problems.
What OpenSSL 3.0 users can do
The last public OpenSSL 3.0 release was 3.0.22 on August 25. OpenSSL said version 3.0.23 is a 3.0 security release that it has not made public; 3.0.23 fixes six of the 14 disclosed problems on September 29, including CVE-2026-84782. For organizations that ship or embed OpenSSL 3.0, OpenSSL recommended upgrading to a newer branch (for example, 4.0 or the long-term support release 3.5) or purchasing a paid support contract to receive fixes for releases past their public end date.
How technologists, distributors, and end users should react
Technologists and security teams: Apply the public OpenSSL updates where possible (4.0.3, 3.6.5, 3.5.9, 3.4.8) and deploy the Ubuntu or Debian packages listed above when those distributions are in use. OpenSSL provides no workaround for systems that cannot update.
Distribution and packaging teams (Ubuntu, Debian, vendors shipping OpenSSL 3.0): Ensure rebuilds and redeployments include the corrected libraries; Ubuntu's packages require a reboot for full effect. Debian maintainers should note that Debian 13 received a fix (DSA-6531-1) while Debian 12 was still listed as vulnerable as of 07:36 UTC on September 30.
Enterprises and end users: Only software that uses OpenSSL for DTLS is exposed. Where DTLS protects services — for example, WebRTC data channels or call-setup key exchange — operators should prioritize updates and restarts according to their patch windows and the vendor packages they use.
Laurent Gaffie of Secorizon reported the flaw on August 17; Ryan Hooper developed the fix. OpenSSL's security policy and public advisories make clear the project expects administrators to install High-rated updates promptly, but the project also left open at least one key technical point: it has not said whether an attacker can reliably cause the resend condition that triggers this leak, and it has not reported any in-the-wild exploitation. That unanswered operational detail will shape how urgently environments that cannot immediately patch must act.
