On September 29, OpenSSL published a security advisory covering 14 vulnerabilities, several rated High. CVE-2026-84782 is one of them: a flaw in DTLS handshake retransmission that can, under specific conditions, send heap fragments to a peer as plaintext or crash the process.
An offset error in DTLS retransmission
DTLS adapts TLS for datagram communication, including UDP. During a handshake, a write can be suspended if the transport cannot immediately accept all fragments. The retransmission logic may run while that write is still waiting to resume.
OpenSSL says the faulty logic reused a read position that did not match the message being retransmitted. It could therefore read bytes from the wrong position, including data from another, larger message still being written. The read may pass the allocated memory boundary; the process can then disclose data or stop.
A scenario tied to handshake state
The issue is not described as an arbitrary request sent to any OpenSSL service. It requires a suspended DTLS write and a retransmission timer firing before that write resumes. The exact impact depends on the application, transport and how it handles write and resume calls.
The advisory rates the issue High and describes heap disclosure or denial of service. It does not report active exploitation. Teams should still check products that use DTLS and should not assume there is no risk simply because they do not run a conventional HTTPS server.
Affected branches and fixed versions
OpenSSL lists versions before the fixes in branches 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 as vulnerable. The listed fixed versions are 4.0.3, 3.6.5, 3.5.9, 3.4.8, 3.0.23, 1.1.1zj and 1.0.2zs. The advisory says unsupported branches 3.1, 3.2 and 3.3 were not analyzed.
Branches 3.0, 1.1.1 and 1.0.2 are outside OpenSSL’s public update channel; corresponding upstream fixes are available only to premium support customers. A distribution may still provide its own backported fix even when the displayed version number looks older. Check your operating system’s or product vendor’s security notice before deciding that an installation remains vulnerable or replacing a library yourself.
What teams can check
Inventory OpenSSL dependencies, including copies bundled with applications and appliances. Determine whether DTLS is enabled or used by a service, then install the fixed version or package supplied by the product maintainer. On managed systems, verify that the fix is actually present after deployment. For examples of patching and post-update checks on other products, see our coverage of the Microsoft Exchange flaw and MikroTik RouterOS vulnerabilities.
How Soclyde fits
Soclyde does not patch OpenSSL or secure applications that include it. To structure security updates, see our NIS2 cybersecurity and tracking guide. This flaw concerns a communications library; a password vault addresses a different need: storing unique account secrets instead of reusing them across services. You can also read our password-manager security audit and guide to creating strong, unique passwords.
Key points
CVE-2026-84782 is a specific flaw in DTLS retransmission that can disclose memory or crash a process under certain handshake conditions. Inventory direct and bundled versions, then apply the affected vendor’s fix. For another example of patch tracking on network equipment, read our report on MikroTik RouterOS vulnerabilities.
