Decoding the world of cybersecurity

OpenSSL fixes high-severity DTLS disclosure flaw

OpenSSL has released security updates for a high-severity DTLS flaw that can expose heap contents as plaintext or crash affected applications during handshake retransmission.

OpenSSL fixes high-severity DTLS disclosure flaw
Summary
  • CVE-2026-84782 affects current OpenSSL 4.0 and 3.x branches as well as maintained legacy 1.1.1 and 1.0.2 releases.
  • Faulty DTLS retransmission handling can disclose heap memory to a peer or cause denial of service.
  • The 29 September security releases also fix additional issues in areas including QUIC, certificate processing, and cryptographic operations.

OpenSSL has released security updates for a high-severity flaw in Datagram Transport Layer Security that can disclose heap memory as plaintext or crash an affected process during handshake retransmission.

CVE-2026-84782 was published on 29 September and affects multiple OpenSSL branches. Fixed releases include 4.0.3, 3.6.5, 3.5.9, 3.4.8, and 3.0.23, with corresponding fixes in maintained legacy 1.1.1 and 1.0.2 releases.

The vulnerability sits in DTLS retransmission logic. OpenSSL says the problem arises when a handshake-message write is suspended part-way through and a retransmission occurs while the same internal buffer and position tracking are still in use.

Under those conditions, the retransmission can begin reading from the wrong position and continue beyond the intended message buffer. Heap contents can then be sent to the peer as plaintext handshake data, or the process can reach unmapped memory and crash.

DTLS provides TLS-style security for datagram communications rather than reliable streams. It is used in software where encrypted communications are required without the ordering and delivery properties of TCP.

That means exposure is not confined to conventional web servers. Embedded systems, communications products, real-time applications, network software, and other products can incorporate DTLS through OpenSSL without presenting administrators with an obvious OpenSSL service.

The dependency chain can make remediation harder than the advisory suggests. OpenSSL is frequently embedded in operating systems, appliances, libraries, firmware, and commercial products. An organisation may therefore depend on a vulnerable build without maintaining it directly.

No active exploitation is identified in the OpenSSL advisory. Actual exposure depends on whether a product uses an affected release and reaches the vulnerable DTLS code path.

The September security releases also address additional vulnerabilities involving DTLS denial of service, QUIC processing, certificate revocation data, and cryptographic operations. The breadth of the release may push organisations towards a wider dependency review rather than treatment of CVE-2026-84782 in isolation.

Where OpenSSL is dynamically provided by an operating system, standard package updates may address the issue. Statically linked applications and embedded firmware can require a supplier to rebuild and redistribute the affected software.

That creates a software supply chain problem as much as a vulnerability-management one. Asset owners may know which product they operate without knowing which cryptographic library version is inside it.

Product manufacturers face increasing regulatory pressure in Europe to understand and maintain third-party software components, particularly as Cyber Resilience Act obligations come into force in stages. Widely reused cryptographic libraries make that dependency particularly visible.

CVE-2026-84782 is not currently a mass exploitation story. Its significance lies in the breadth of OpenSSL’s use and the possibility that affected code is buried inside products whose owners cannot patch the library independently.

×