OpenSSL Ships a Pile of Fixes, and a DTLS Bug That Can Spill Memory to the Wrong Side of the Wire

Key points

• Debian's DSA-6531-1 advisory lists 13 OpenSSL CVEs patched together in trixie, an unusually large batch for a single security update.
• The headline bug lets a DTLS handshake, the encryption used for UDP traffic like voice and video, leak raw memory contents to the other end of the connection or crash the process.
• Ubuntu's USN-8847-1 notice confirms one flaw, a QUIC amplification accounting bug, only affects Ubuntu 26.04 LTS.
• Two of the fixes are timing side-channel issues in elliptic curve maths, including one specific to ARM64 servers running the Chinese SM2 curve.
• OpenSSL published fixes on September 29; distribution packages followed within days.

OpenSSL just shipped one of its noisiest updates of the year, and the reason your Linux servers pulled a fresh package this week is buried in a list of 13 separate CVE numbers.

The one everyone should read first is the DTLS flaw. DTLS is the version of TLS, the padlock protocol behind HTTPS, that runs over UDP instead of TCP. It shows up in WebRTC video calls, VPN tunnels and a lot of embedded gear. Because UDP does not guarantee delivery, DTLS retransmits handshake messages when a timer runs out. In practice, the failure mode here is that if a large handshake message is only partly sent when the retransmit fires, OpenSSL can end up putting uninitialised heap memory, whatever happened to be sitting in RAM, into the packet it sends to the other side. That memory can contain keys, session data, or fragments of other users' traffic. The same code path can also crash the process outright.

OpenSSL released the fix on September 29, as first reported by The Hacker News.

What did Debian and Ubuntu actually patch?

A lot, in one go. Debian's advisory rolls up 13 CVEs into a single OpenSSL update for trixie, moving the package from 3.5.7-1deb13u2 to 3.5.7-1deb13u3. Ubuntu's parallel notice covers the same cluster for supported releases.

The bugs are not all the same shape. A few stand out.

The CVE-2026-54872 record is the one that will bother anyone running non-standard curves. A timing side channel means an attacker who can measure how long cryptographic operations take, sometimes over a network, can slowly work out the secret key by watching for tiny differences.

Should ordinary users do anything?

Probably not directly. This is a plumbing update. If you run a laptop or a phone, your operating system will pull the fix in the background the next time it updates, and the browsers and apps that use OpenSSL will pick it up on restart.

The people who need to move are the ones running servers, VPN concentrators, load balancers and any embedded product that statically links OpenSSL. That last group is the one that always bites. One thing the post-mortem will say, six months from now when someone finds a still-vulnerable box, is that nobody had a list of which appliances shipped with OpenSSL baked in.

How bad is the DTLS bug in practice?

Bad enough that OpenSSL rated it High, not Critical. The leak is not a full private key dump on demand. It is a stream of whatever heap memory happens to be sitting near the handshake buffer, sent unencrypted to the peer. In a busy server that terminates thousands of DTLS sessions, that peer can be an attacker who just keeps opening connections and collecting the scraps.

The honest read: patch the servers this week, audit anything that speaks DTLS or QUIC, and ask your appliance vendors in writing which OpenSSL version they ship. If they cannot answer, that is your answer.

Operational takeaway: rebuild container base images now, because the fix does nothing for you until the binaries on disk actually change.