Am I vulnerable? Check installed package versions against an advisory

Updated November 2026

To find out whether a server is vulnerable, compare the installed package version with the fixed version in your distribution’s advisory, not with the upstream version in the news. Distributions usually backport fixes into older versions, so a version number that looks old can be fully patched.

Backporting in plain words

When a project such as OpenSSH fixes a security bug, it releases a new upstream version. Stable distributions usually do not ship that new version. Instead, they take only the security fix and apply it to the version they already ship, then add to the package’s release number. This is called backporting.

Debian’s security FAQ says it backports “security fixes to the version that was shipped in the stable release” so that things do not “change or break unexpectedly”. Red Hat says this is its default practice for most products, and warns that “just looking at the version number of a package will not tell them if they are vulnerable or not.”

A real example: upstream OpenSSH fixed CVE-2024-6387 in version 9.8p1. Ubuntu 24.04 LTS lists the fix in 1:9.6p1-3ubuntu13.3. That package says “9.6”, which is lower than 9.8, yet it is fixed. Read the version in three parts:

Parts of a Debian/Ubuntu package version
PartExampleMeaning
Epoch1:Rarely changes; overrides normal ordering
Upstream version9.6p1The upstream release the package is based on
Revision-3ubuntu13.3Distribution changes, including backported fixes

RPM packages work the same way. SUSE lists the fix for SLES 15 SP6 as openssh 9.6p1-150600.6.3.1 or later: upstream 9.6p1, and a release number that carries the fix. So the rule is simple. Look up the fixed version for your release in the vendor’s tracker, then check whether the installed version is equal or newer.

Where to find the fixed version

These pages also tell you when a release is “not affected”, for example because it ships a version from before the bug was introduced. More on each vendor’s feeds is in Security advisories.

Debian and Ubuntu

# Installed version (ii = installed)
dpkg -l 'openssh*'
dpkg-query -W -f='${Version}\n' openssh-server

# Installed vs candidate version from the repositories
sudo apt update
apt-cache policy openssh-server

# Does the changelog of the installed version mention the CVE?
apt-get changelog openssh-server | grep CVE-2024-6387

# Compare with the fixed version from the advisory
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' openssh-server)" ge 1:9.6p1-3ubuntu13.3 \
  && echo fixed || echo NOT fixed

apt-cache policy shows the Installed and Candidate versions. If the candidate is newer, an update is waiting. apt-get changelog downloads the changelog of the installed version by default, so it needs network access. dpkg --compare-versions uses the same ordering rules as the package manager, which is safer than comparing by eye.

On Debian, debsecan lists vulnerabilities that affect installed packages, using data from the Debian security tracker. Give it your release code name (for example trixie), not “stable”:

sudo apt install debsecan
debsecan --suite trixie --only-fixed --format packages   # packages with a fix available
debsecan --suite trixie --format detail | grep CVE-2024-6387

RHEL, Rocky, AlmaLinux and Fedora

# Installed version
rpm -q openssh-server

# Does the package changelog mention the CVE?
rpm -q --changelog openssh-server | grep CVE-2024-6387

# DNF 4 (RHEL 8, 9, 10 and rebuilds): advisories for this CVE
dnf updateinfo list --cve=CVE-2024-6387                # not yet installed
dnf updateinfo list --installed --cve=CVE-2024-6387    # already installed
dnf updateinfo info --cve=CVE-2024-6387                # full advisory text
dnf updateinfo list --updates --security               # all pending security updates

# DNF5 (newer Fedora): the advisory command
dnf advisory list --cves=CVE-2024-6387

A match in rpm -q --changelog is good evidence that the fix is in, because packagers usually name the CVE in the changelog entry. No match is not proof of the opposite. Some fixes are listed only in the advisory, so check the advisory’s fixed version too. Check which DNF you have with dnf --version.

SUSE and openSUSE

sudo zypper refresh

# Installed and available version
zypper info openssh
zypper search -s -i openssh

# Patches that fix this CVE and are still needed
zypper list-patches --cve=CVE-2024-6387

# All needed security patches
zypper list-patches --category security

SUSE ships fixes as patches, which group updated packages. If zypper list-patches --cve shows nothing for a CVE that affects your product, the patch is either already installed or not released yet. Check the SUSE CVE page to tell which. Use zypper patch-info with a patch name to see which issues it fixes.

Alpine Linux

apk update                       # as root
apk info -v | grep openssh       # installed name-version
apk policy openssh               # versions available in your repositories
apk version -l '<'               # installed packages older than the repository
apk version -t 1.2.3-r0 1.2.3-r1    # compare two version strings: prints <, = or >

Alpine fixes go into the package release number (the -rN part). Look up the fixed version for your Alpine branch (for example v3.22) in the Alpine Security Tracker, then compare.

FreeBSD

# Run as root, or with sudo/doas if installed
# Installed packages with known vulnerabilities (fetches the VuXML database first)
sudo pkg audit -F

# Also show packages that depend on vulnerable ones
sudo pkg audit -F -r

# Installed version of one package
pkg info openssh-portable

# Packages with a newer version in the repository
sudo pkg update
pkg version -vRL=

# Base system patch level: installed kernel, running kernel, userland
freebsd-version -kru

pkg audit checks third-party packages against VuXML. Flaws in the base system (the kernel and tools such as the bundled OpenSSH and OpenSSL) are announced as FreeBSD Security Advisories. Each advisory lists the patch level that fixes the issue. Compare it with freebsd-version. If -k and -r differ, a new kernel is installed but you have not rebooted yet.

Common mistakes

Sources