CVE-2026-84782

What it actually does

OpenSSL DTLS handshake retransmission can perform an out-of-bounds read of a shared message buffer when a handshake write is suspended mid-fragment (WANT_WRITE) and the retransmission timer fires. The retransmit path reuses the same buffer and write-position state without resetting to the start of the queued message, so leftover bytes—or memory past the allocated buffer—are sent to the peer as plaintext handshake content. Completing a retransmit while another write is still suspended also corrupts the bookkeeping the suspended write needs to resume, which can abort the process (debug builds) or crash when the read hits unmapped memory. Confidentiality impact is limited heap disclosure over the DTLS handshake; integrity is unaffected; availability impact is high (DoS). The affected code is outside the FIPS module boundary.

Why it matters to the business

Any service that terminates DTLS (VPNs, IoT/device management, media, custom UDP TLS stacks, and language runtimes that bundle OpenSSL) can leak fragments of process heap to an unauthenticated network peer or be crashed by a remote handshake. Impact is operational outage of DTLS listeners plus potential exposure of residual secrets or adjacent heap objects in the same process. The issue is four days old, not in CISA KEV, has no known in-the-wild exploitation, and a low, flat EPSS (~0.0039). Urgency is still high for internet-facing DTLS because CVSS is 8.2 (network, unauthenticated, high availability) and OpenSSL is widely embedded (Red Hat openssl, openssl3, python-cryptography, Ruby 3.3/3.4, rust-bootupd, chunkah). Non-DTLS TLS-only deployments are not in the described attack surface.

How an attack unfolds

An unauthenticated network attacker opens a DTLS handshake with a vulnerable OpenSSL-based server or client and drives the handshake so that a handshake message is written in fragments. When the underlying UDP transport cannot accept more data, the write suspends mid-message. Independently, the DTLS retransmission timer fires and the stack attempts to resend an earlier queued handshake message using the same internal buffer and cursor. Because the cursor is not reset, the retransmit is assembled from leftover bytes of the in-flight larger message and can run past the buffer, sending heap contents to the attacker as a mislabelled handshake fragment, or faulting if the read reaches unmapped memory. Even without an OOB read, allowing the retransmit to finish while a write remains suspended overwrites shared state; the next SSL_read/SSL_write/SSL_accept/SSL_connect that resumes the write can abort the process. No named threat actors or ransomware campaigns are associated, and public exploit maturity is none.

How to fix it

Patch OpenSSL and all downstream packages that ship the affected DTLS retransmission logic. On Red Hat-derived streams apply RHSA-2026:74162: openssl-main and openssl3-main to 3.5.9-0.1.hum1, python-cryptography-main to 50.0.0-1.hum1, ruby3-3-main to 3.3.10-23.6.hum1, ruby3-4-main to 3.4.10-31.7.hum1, rust-bootupd-main to 0.3.2-1.hum1, chunkah-main to 0.7.0-1.1.hum1. Upstream OpenSSL fix resets the retransmission read position to the start of the message and skips retransmission entirely while a handshake write is suspended. If DTLS is not required, disable DTLS listeners and DTLS client use until patched. Prioritize internet-facing DTLS VPNs, device gateways, and any process that both speaks DTLS and holds long-lived secrets in the same address space. Rebuild and redeploy statically linked binaries (Go/Rust/custom appliances) that vendor OpenSSL rather than assuming a distro libssl update is sufficient. FIPS-validated module boundary is not implicated; still patch the non-FIPS DTLS path.

How to confirm the fix worked

Inventory every package and statically linked binary that provides libssl/DTLS (openssl, openssl3, python-cryptography, Ruby with OpenSSL, rust-bootupd, chunkah, and custom OpenSSL builds). Confirm installed versions match or exceed the RHSA-2026:74162 fixed versions listed above, or that the OpenSSL sources include the retransmission cursor reset and the skip-retransmit-while-write-suspended change. After upgrade, exercise DTLS handshake under write pressure (fragmented handshake records and delayed UDP) and confirm the process neither crashes nor emits unexpected handshake payloads. For TLS-only services, verify DTLS is not compiled in or not bound to a socket. Regression-test SSL_accept/SSL_connect/SSL_read/SSL_write resume after WANT_WRITE. Track vendor advisories for any remaining language runtimes that bundle OpenSSL.

Typical attack path

1. Identify a network-reachable DTLS endpoint using a vulnerable OpenSSL (or bundled OpenSSL) stack
2. Initiate a DTLS handshake and keep the peer writing handshake messages that can fragment
3. Cause the transport to stall so a handshake write suspends mid-message (WANT_WRITE)
4. Allow or induce the DTLS retransmission timer to fire while that write is still suspended
5. Receive a mislabelled retransmit whose body contains leftover handshake bytes or adjacent heap, or observe the peer crash/abort
6. Repeat against the same listener to sustain denial of service if the process does not recover

How to detect it

There are no public exploits, KEV listings, or named APT/ransomware associations, so look for failed or crashing DTLS handshakes rather than a known payload. Collect process crash dumps and core files from services linked to libssl/libcrypto that speak DTLS; abort/assert in debug builds on SSL_read, SSL_write, SSL_accept, or SSL_connect after WANT_WRITE is a strong signal. Network: packet captures of DTLS (typically UDP) showing handshake retransmission while the peer is still flushing a fragmented handshake message, or handshake records whose length/content do not match the declared handshake type. Host: sudden restarts of OpenSSL-based DTLS daemons, systemd/journald crash units, and language runtimes (Python cryptography, Ruby, Rust bootupd) dying during DTLS connect/accept. Hunt four days of logs since publication for clustered UDP handshake failures from the same source to the same DTLS port. Absence of these artifacts does not prove non-exploitation of the heap-disclosure path, which may look like a single anomalous handshake record.

• DTLS handshake retransmission concurrent with a suspended WANT_WRITE handshake write
• libssl/libcrypto abort or SIGSEGV during SSL_accept, SSL_connect, SSL_read, or SSL_write on a DTLS socket
• handshake fragment whose body length or content does not match the handshake message header (mislabelled retransmit)
• core dumps or journald entries for openssl, stunnel, nginx/stream DTLS, python-cryptography, ruby, or bootupd dying in dtls1/retransmission paths
• repeated unauthenticated UDP connections to DTLS ports that stall mid-handshake then trigger retransmit timers

What your security team should do

• Patch internet-facing DTLS terminators first (VPN, IoT, media, custom UDP TLS) using RHSA-2026:74162 or equivalent OpenSSL 3.5.9-based fixes within days, even though the CVE is not KEV and EPSS is low
• Enumerate DTLS listeners and statically linked OpenSSL consumers (python-cryptography, Ruby 3.3/3.4, rust-bootupd, appliances) so distro libssl upgrades are not assumed to cover all copies
• If patching is delayed, disable or firewall DTLS (UDP 443/3391/other DTLS ports) at the edge; TLS-over-TCP is not the described vector
• Watch for process crashes in libssl during handshake and unexpected DTLS handshake fragments; there is no public exploit and no named actor, so treat crashes as the primary early warning
• Rebuild and redeploy any internally built OpenSSL, FIPS-adjacent products still ship the non-FIPS DTLS path and must be updated separately