OpenSSL on Linux: which version fixes what

What it is, and why it is on your server

OpenSSL provides the TLS and cryptography that nginx, Apache, Postfix, MySQL, PHP, Python and most of the rest of the system use. It is rarely a process of its own; it is a shared library mapped into many.

Why its advisories behave the way they do

• A patched package is not a patched server. Upgrading libssl replaces the file on disk, but every process that already mapped the old copy keeps using it until it restarts. This is the single most common reason a server shows as vulnerable after the administrator is certain it was updated.
• The blast radius is the whole machine. A flaw in certificate parsing is reachable through every service that terminates TLS, which is usually the web server, the mail server and the database at once.
• Version numbers here are genuinely confusing. A distribution may ship 3.0.13 with two years of security fixes backported into it, so "3.0.13 is old" is not a finding and the package revision after the dash is what counts.

Check what you are actually running

The version that matters is the package version, not the upstream one. Distributions backport security fixes without changing the number before the dash, so a release that looks years old is frequently fully patched, and the revision after the dash is the only part that tells you.

dpkg-query -W -f='${Package} ${Version}\n' openssl libssl3 2>/dev/null

rpm -q openssl openssl-libs

After upgrading, `needrestart -r l` on Debian and Ubuntu, or `dnf needs-restarting -r` on Rocky and AlmaLinux, will tell you which running processes are still holding the old library.

Fixed versions, per distribution

Each distribution patches on its own schedule and under its own version scheme, so the same CVE has a different answer on each of them. These come from the distributions’ own advisory data, asked per release. Where a release has no fixed version, that is what the advisory says, not a gap in the data.

Advisory data last refreshed 26 September 2026. It is re-read daily.

What this page does not tell you

It does not tell you whether your server is affected. A CVE applying to a package is not the same as a CVE applying to your installation: the fix may already be backported into what you are running, the vulnerable module may not be loaded, or the service may not be reachable from anywhere that matters. Answering that needs the versions on your machine, not a list.

It also carries no count of how many servers are affected. SecAI monitors a small fleet, and a percentage drawn from it would be arithmetic on a sample too small to mean anything. When that changes, the number will appear here and the page will say when it started.

Read next