OpenSSL 3.0.23 exists. You can't have it.

The August MOTD on OpenSSL 3.0 EOL said: after September 7, there are no more public security patches for 3.0. Six weeks later, that stopped being a hypothetical.

On September 29, the OpenSSL project disclosed 14 security issues across the 4.x and 3.x branches. Six of those affect 3.0. The worst is CVE-2026-84782.

The DTLS retransmission handler in OpenSSL 3.0 can reference a stale buffer offset when retransmitting handshake messages. Depending on heap layout, this leaks heap contents into the network in plaintext, or it segfaults the process. DTLS is the underlying transport for a lot of VPN software, older QUIC implementations, and anything using TLS over UDP rather than TCP. If your server speaks DTLS to clients you don’t control, they can trigger this without authenticating first.

Severity is high.

The fix is in OpenSSL 3.0.23. OpenSSL 3.0.23 is not public. Premium support contract holders can download it. Everyone else is on 3.0.22 and shipping the vulnerability.

The public releases, 4.0.3, 3.6.5, 3.5.9, and 3.4.8, all carry the fix. The project is not being subtle about the intended path.

Who this actually bites

If you installed OpenSSL from your distro’s package manager on Ubuntu 22.04 or 24.04 LTS, Debian 12, or similar, you’re probably fine. Those distributions maintain their own backport patch queue and patch CVEs into their frozen 3.0 package regardless of what upstream does. The EOL of the upstream 3.0 branch does not end their support window. You’ll get the fix without any action on your part.

The exposures are elsewhere.

Static binaries that linked OpenSSL at build time. The binary carries the OpenSSL it was compiled against. Your CI built it six months ago against 3.0.21 or 3.0.22. It is on your servers. It is not getting patched.

Vendored copies inside language runtime distributions. Some Python and Node.js binary builds ship a private copy of libssl. Run strings /path/to/binary | grep 'OpenSSL 3\.' to find out if you’re carrying one.

Container images that install OpenSSL outside the base distro’s package manager, or that were built off an old base image and never rebuilt. A container built from a 2024 base with a pinned apt-get install openssl is sitting on whatever version was current then, and it will stay there.

Commercial appliances and firmware with a baked-in libssl. You are not patching those. The question is whether the vendor backports on their own schedule, and when.

How to check

Find out what you’re running:

openssl version -a

Find bundled copies:

find / -name 'libssl.so.3*' 2>/dev/null
strings /path/to/binary | grep 'OpenSSL 3\.'

For containers, run this against the image before it hits prod:

docker run --rm <image> find / -name 'libssl.so.3*' 2>/dev/null

What to do about it

If you’re on 3.0 and not covered by a distro backport, migrate to OpenSSL 3.5 LTS. It’s supported until April 2030. The migration from 3.0 to 3.5 has some rough edges: the FIPS provider configuration changed, some deprecated functions were removed, and the provider loading model got stricter. The upstream migration guide covers all of it. It is work. An unauthenticated heap leak through your DTLS stack is also work, just the kind you do at 3am.

If 3.5 is not yet feasible, 3.4 is also public and also has the fix.

If neither migration is on the table immediately, you need to treat 3.0 as indefinitely unpatched until you do migrate, because that is what it is. The NVD and OSV feed changes from August are relevant here: downstream CVE tracking for 3.0.x will diverge from upstream. You will not get clean automated alerts.

This was always where this ended up. The OpenSSL project published the EOL policy in 2021 when 3.0 launched. LTS support ends, patches end. The policy was not secret. What it takes, apparently, is a high-severity CVE with no public fix to make it concrete enough to act on. That CVE is now here.

The DTLS mechanism and the vDSO-backed getrandom path it relies on for key material are both covered in the getrandom vDSO tip if you’re working on the plumbing level.