When the library that encrypts half the internet sneezes, every server operator catches a cold. On September 29, the OpenSSL project published a security advisory covering fourteen vulnerabilities and released OpenSSL 4.0.3 as the fix for the current 4.0 line — alongside patched releases for the 3.6, 3.5, and 3.4 branches. In the project's own words, "the most severe CVE fixed in this release is High." That sentence deserves unpacking, because the most interesting bug in this batch isn't interesting for its severity rating.

The headline bug: DTLS retransmission reads the wrong memory

The worst-rated flaw is CVE-2026-84782, a High-severity out-of-bounds read in DTLS — the variant of TLS designed for UDP traffic. DTLS splits large handshake messages into fragments that fit inside single UDP datagrams. If the transport momentarily can't accept more data, sending a big message can pause halfway through and resume later. Meanwhile, a retransmission timer can fire and ask the stack to resend an earlier handshake message.

Before the fix, the retransmission reused the buffer position of the paused write instead of rewinding to the start of the message being resent. The resent message went out with the wrong contents: leftover bytes from the larger, unrelated message still in transit — potentially heap memory, sent to the peer as unencrypted handshake data. Read far enough past the buffer and the process crashes instead, which is the denial-of-service half of the bug. There is a second, subtler failure in the same path: a retransmission can corrupt the bookkeeping a suspended write needs to resume, aborting the process when the application later calls back in.

A few facts keep the panic proportional. The flaw was reported on August 17 by Laurent Gaffie of SecuRizon and fixed by Ryan Hooper; OpenSSL has not reported any in-the-wild exploitation, and has not said whether an attacker can reliably force the pause-and-retransmit overlap. Software is only exposed if it actually uses OpenSSL for DTLS — think WebRTC data channels and VoIP key exchange, not your average HTTPS server. TLS-only applications are untouched by this specific bug, and the OpenSSL FIPS module is unaffected since the vulnerable code sits outside its boundary.

The rest of the batch, and the bug with no CVE

Fourteen CVEs is a lot of surface area. Beyond the DTLS headline there is CVE-2026-84783, a use-after-free in the X.509 extension cache under concurrent use, plus a cluster of QUIC fixes: excessive amplification credit accounting, a CPU denial-of-service in fragment reassembly, a STREAM fragment metadata DoS, missing connection-level flow control, and an unbounded RETIRE_CONNECTION_ID backlog. Cryptographic code gets attention too — timing side channels in scalar multiplication on non-NIST curves and SM2 signature generation, including non-constant-time SM2 paths on ARM64 and RISC-V.

But the fix I'd actually lose sleep over carries no CVE number. In the AES-SIV path, EVP_DecryptFinal() could report a stale success after an authentication failure — meaning an application that trusts the return value to confirm integrity could treat tampered plaintext as legitimate. That is a correctness bug in authenticated encryption, the exact place correctness matters most, and it will sail straight past any dashboard that only tracks CVE severity. The same release also fixes a base64 BIO filter regression that could silently lose encoded data after incomplete writes.

The quiet end-of-life hiding in the advisory

Buried in the release notes is a deadline: OpenSSL 3.0 stopped receiving public security fixes on September 7, 2026. The fixed versions for the 3.0, 1.1.1, and 1.0.2 branches — 3.0.23, 1.1.1zj, 1.0.2zs — go only to premium support customers. If your fleet still runs a 3.0-series library, this advisory is your nudge to plan the move: 3.5 is the long-term support branch (until April 2030), and 4.0 is the current major line.

The patch drill

Here is the part that matters on a Monday morning:

  1. Check what you actually run. openssl version tells you about the CLI, not the library your services link against. Check the distro package: dpkg -l | grep libssl on Debian/Ubuntu, rpm -qa | grep -i openssl on RPM systems.
  2. Don't judge by upstream version numbers. Distros backport fixes into older package versions. Read the distro's security notice, not the version string. Ubuntu patched on September 29 — 26.04 got libssl3t64 3.5.5-1ubuntu3.6, 24.04 got 3.0.13-0ubuntu3.16, 22.04 got 3.0.2-0ubuntu1.30 — and its notice says to reboot. Debian shipped DSA-6531-1 (3.5.7-1~deb13u3) for Debian 13, while Debian 12 was still listed vulnerable on September 30.
  3. Scope your exposure before you panic. Inventory which of your services actually speak DTLS. WebRTC gateways, VoIP servers, some VPN setups — those go first. A fleet of TLS-only web servers still wants the patch (the QUIC and X.509 fixes apply broadly), but the DTLS memory leak doesn't threaten them.
  4. Restart what links against it — or just reboot. Everything from nginx to sshd loads libssl. A patched library on disk protects nothing until the running processes pick it up. Ubuntu's "reboot after the update" advice is blunt and correct.
  5. Keep the loop boring: inventory, prioritize, test, verify the patched library is actually loaded (sudo lsof | grep libssl will ruin your afternoon in the best way).

OpenSSL had a rougher batch back in January with remote-code-execution potential; this one is memory disclosure and denial of service. Neither is the story. The story is that the most depended-upon library in your stack just changed, quietly, on a Monday — and the operators who have a drill didn't need the headline to tell them what to do.

Sources: OpenSSL Project security advisories (openssl.org) — September 29, 2026 batch, CVE-2026-84782 / CVE-2026-84783; Ubuntu Security Notices for libssl (September 29, 2026); Debian Security Advisory DSA-6531-1.