OpenSSL has released security updates for a high-severity vulnerability that could expose heap memory as plaintext during Datagram Transport Layer Security (DTLS) handshakes.

Tracked as CVE-2026-84782, the flaw stems from an out-of-bounds read in DTLS handshake retransmission logic and can also crash an affected process, creating a denial-of-service condition.

The OpenSSL Project disclosed the issue on September 29, 2026, alongside security releases OpenSSL 4.0.3, 3.6.5, 3.5.9 and 3.4.8. OpenSSL described those releases as security patches and said the most severe vulnerability corrected in each is rated High.

OpenSSL Leak Server Memory

DTLS provides TLS-style security over unreliable datagram transports, where packets may be delayed, reordered, or lost. Consequently, its handshake layer can fragment large messages and retransmit previously sent data when a timer expires.

CVE-2026-84782 emerges when OpenSSL suspends a handshake-message write partway through because its transport cannot accept more data, returning WANT_WRITE.

While that write remains suspended, a retransmission timer can request that an earlier handshake message be sent again. Vulnerable OpenSSL versions reused the internal buffer and position tracking associated with the interrupted write but failed to reset the read offset to the beginning of the queued message.

The retransmission could therefore begin at a stale position, attach leftover bytes from a different, larger message, and continue reading beyond the allocated buffer.

That behavior may send adjacent heap contents to the connected peer as plaintext handshake data. The exposed bytes depend on nearby process memory contents, so the advisory does not define a fixed set of secrets that will always leak.

If the out-of-bounds flaw impacts an unmapped memory region, the process may instead terminate, allowing a peer to trigger denial of service. OpenSSL classifies the weakness as CWE-125, an out-of-bounds read.

The bug creates a second state-management problem. Even when retransmission starts at the correct offset, completing it while another handshake write is paused overwrites shared bookkeeping needed to resume the original operation. A later SSL_read(), SSL_write(), SSL_accept() or SSL_connect() call can then encounter state inconsistent with the suspended message; OpenSSL says this causes an abort in debugging builds.

OpenSSL fixed the vulnerability by resetting the retransmission read position before resending a message. The code also skips retransmission while a handshake write remains suspended, deferring work until a later call resumes it. The affected logic sits outside the OpenSSL FIPS module boundary, so the project says FIPS modules are not impacted.

All branches are vulnerable: OpenSSL 4.0 before 4.0.3, 3.6 before 3.6.5, 3.5 before 3.5.9, 3.4 before 3.4.8, 3.0 before 3.0.23, 1.1.1 before 1.1.1zj and 1.0.2 before 1.0.2zs. Fixes for the three oldest branches are limited to premium support customers.

Administrators should inventory appliances, embedded systems, VPN products, and applications that use OpenSSL DTLS, then upgrade through their operating-system or product vendor.

Updating to 4.0.3, 3.6.5, 3.5.9 or 3.4.8 addresses the issue on maintained branches, while supported customers should obtain 3.0.23, 1.1.1zj or 1.0.2zs. Because applications may bundle OpenSSL rather than use the system library, checking only the host package manager may miss exposed copies.

Laurent Gaffie of Secorizon reported CVE-2026-84782 on August 17, 2026, and Ryan Hooper developed the correction after receiving the report in August.

OpenSSL 4.0.3 also addresses 13 additional vulnerabilities affecting X.509 processing, QUIC, CMP, DTLS, SM2, and elliptic-curve operations, reinforcing the need to treat this release as a security update rather than a single-bug patch.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup into your SOC

The post OpenSSL Fixes High-Severity Flaw That Can Leak Server Memory in Plaintext appeared first on Cyber Security News.