By Cyber Defense Technologies October 23, 2026 4 min read
On September 29, 2026, OpenSSL published fixes for CVE-2026-84782, a high-severity out-of-bounds read in its DTLS code. A malicious or misbehaving peer could cause an affected application to send fragments of its heap memory as handshake data, or to crash. The flaw is limited to DTLS, the datagram version of TLS, which makes the first question for most organizations simple: do we use it, and where?
As of October 22, 2026, the details below come from the OpenSSL security advisory and the NVD record. Check them for updates.
What DTLS is and where it is used
TLS secures connections that run over TCP, such as HTTPS. DTLS provides similar protection for traffic over UDP, which is used where low latency matters more than guaranteed delivery. Common uses include:
- VPNs, where some remote access products carry tunnel traffic over DTLS for better performance.
- Voice and video, including WebRTC, which uses DTLS to set up encrypted media sessions, and some VoIP systems.
- IoT and operational technology, where constrained devices often use DTLS with lightweight protocols such as CoAP.
A product is only exposed if it uses OpenSSL's DTLS implementation. Many DTLS deployments use other libraries, so the answer depends on what each product is built with.
What the flaw does
DTLS resends handshake messages when it does not get a timely response. OpenSSL's advisory explains that if a handshake write is suspended partway through and the retransmission timer fires, the resent message can be read from the wrong position and past the end of its buffer. The impact, in OpenSSL's words, is that the message can disclose heap memory to the peer as plaintext handshake data, or crash the process if the read reaches unmapped memory.
OpenSSL rates the issue high severity. The NVD record lists a CVSS v3.1 score of 8.2. The advisory describes the flaw only in DTLS retransmission handling and does not identify any impact on ordinary TLS over TCP. It also notes that the FIPS module is not affected because the code is outside its boundary. That does not exempt FIPS deployments, since the DTLS code is in the main library.
Affected and fixed versions
- OpenSSL 4.0 before 4.0.3
- OpenSSL 3.6 before 3.6.5
- OpenSSL 3.5 before 3.5.9
- OpenSSL 3.4 before 3.4.8
- OpenSSL 3.0, 1.1.1 and 1.0.2 are also affected. Fixed versions (3.0.23, 1.1.1zj and 1.0.2zs) are listed for premium support customers only.
OpenSSL 3.1, 3.2 and 3.3 are out of support and were not analyzed. The same release also fixed 13 other issues, one rated moderate and the rest low, so updating covers more than this CVE.
Why your version number may not match
Many organizations get OpenSSL from their operating system rather than from openssl.org. Enterprise and long-term-support distributions such as Ubuntu and Red Hat Enterprise Linux typically keep the same base version for the life of a release and backport security fixes into it. A system can report an older-looking version and still be patched, or report a supported version and be missing the fix.
Do not judge exposure by the version string alone. Check your distribution's security tracker or advisory for CVE-2026-84782 and confirm the installed package release includes the fix.
Find every copy
The system OpenSSL package is only part of the picture. Look for:
- Applications that bundle or statically link their own OpenSSL, which operating system updates will not fix.
- Container images that need to be rebuilt with updated base layers.
- Appliances and embedded devices, such as VPN gateways, voice systems and IoT or OT equipment, where only the vendor can supply a fix.
Software composition analysis and vulnerability scanners can find many embedded copies, but vendor confirmation is often the only reliable answer for appliances.
Patch and reduce exposure
- Update to a fixed upstream release or your vendor's patched package, then restart services so they load the new library.
- Prioritize DTLS services reachable from untrusted networks, such as internet-facing VPN and voice endpoints.
- Ask vendors whether their products use OpenSSL for DTLS and when fixes will ship.
- Turn off DTLS where it is not needed, and restrict UDP access to the services that remain.
The OpenSSL advisory does not list a workaround. Restricting exposure lowers risk while patches are pending but is not a substitute for the fix.
What to tell leadership
This is a targeted issue, not an internet-wide emergency, but it can leak memory from systems that handle sensitive connections. Report which products use DTLS, which are confirmed patched, which depend on vendor fixes, and the expected dates.
How CDT can help
CDT's hardening engineers help organizations inventory cryptographic libraries, apply fixes and reduce unnecessary exposure, and our managed security team monitors the systems that matter most.
