How to Check if Your Ubuntu Server Is Affected by a CVE

To check a CVE on Ubuntu, run pro fix CVE-ID --dry-run, which names the affected package, says whether a fix exists, and reports whether a reboot is needed. Compare versions with Ubuntu's tracker rather than upstream, because Ubuntu backports fixes. For kernel flaws, also confirm which kernel is actually running.

The output below comes from Ubuntu 24.04 in a systemd-booted container under WSL2, run on November 5, 2026, so the running kernel wasn't an Ubuntu one. Security status changes daily, so treat the CVE details as a snapshot and run the commands yourself.

What Is the Fastest Way to Check a CVE?

pro fix comes with the Ubuntu Pro client, and it works without a subscription for anything in the standard repositories. Add --dry-run to see the result without installing anything:

sudo pro fix CVE-2026-109518 --dry-run

WARNING: The option --dry-run is being used.
No packages will be installed when running this command.
CVE-2026-109518: APT vulnerability
 - https://ubuntu.com/security/CVE-2026-109518

1 affected source package is installed: apt
(1/1) apt:
A fix is available in Ubuntu standard updates.
{ apt update && apt install --only-upgrade -y apt apt-utils libapt-pkg6.0t64 }

✔ CVE-2026-109518 is resolved.

Don't read that last line as your current status. In a dry run it describes what would happen, and apt was still the old version when this printed.

The middle of the output is what you want. These are the results I saw, and what each one means for you:

How Do You Compare Versions by Hand?

Use the Ubuntu CVE tracker, and compare with dpkg, because these version strings don't sort the way they look:

installed=$(dpkg-query -W -f='${Version}' apt)
dpkg --compare-versions "$installed" ge 2.8.4ubuntu0.1 && echo patched || echo "needs update"

That printed needs update on 2.7.14build2 and patched on 2.8.4ubuntu0.1.

The changelog shows which CVEs a package fixed:

apt-get changelog apt | head -6

Get:1 https://changelogs.ubuntu.com apt 2.8.4ubuntu0.1 Changelog [518 kB]
apt (2.8.4ubuntu0.1) noble-security; urgency=medium

  * SECURITY UPDATE: Download verification bypass
    - methods/*.cc: Open target files exclusively
    - CVE-2026-109518

Don't compare against the upstream version. Ubuntu backports fixes, so openssh-server on my 24.04 machine is 1:9.6p1-3ubuntu13.20, and it still reports itself as OpenSSH 9.6. A scanner that reads only the SSH banner will flag fixes you already have, and the tracker is what settles it.

Why Are Kernel CVEs Different?

Because the fix doesn't apply until you reboot. Check what's running against what's installed:

uname -r
dpkg -l 'linux-image-[0-9]*' | grep ^ii
cat /var/run/reboot-required.pkgs

pro fix does read the reboot flag. With the flag present, pro fix reported the CVE as not resolved even though the package was installed:

(1/1) linux:
A fix is available in Ubuntu standard updates.
The update is already installed.

A reboot is required to complete fix operation.
✘ CVE-2026-31431 is not resolved.

Without the flag it reported the same CVE as resolved, and my test machine's running kernel wasn't that package at all. So uname -r is the check you can't skip.

By default, unattended upgrades won't reboot for you, which makes this the most common gap on otherwise patched servers.

Containers don't get their own kernel. docker run --rm alpine uname -r printed the host's kernel version, so a kernel flaw on the host applies to every container on it.

Are Your Docker Containers Patched?

Not by anything you do on the host. After patching apt on the server, I checked it inside a container from a pulled image:

dpkg-query -W -f='${Version}\n' apt
docker run --rm ubuntu:24.04 dpkg-query -W -f='${Version}\n' apt

2.8.4ubuntu0.1
2.8.3

Library fixes reach a container only when you rebuild its image from a fresh base and redeploy:

docker build --pull -t your-app:new .

A scanner can tell you what's stale, but pin it like anything else you pull. Trivy's own Docker Hub images were compromised in March 2026, including the latest tag, and Docker's advice after that was to pin images by digest and verify signed provenance where it's available.

What Ubuntu Doesn't Patch for You

pro security-status tells you how many packages come from somewhere else:

231 packages installed:
    226 packages from Ubuntu Main/Restricted repository
    1 package from Ubuntu Universe/Multiverse repository
    4 packages from third parties

On a Docker host, those third parties usually include Docker itself, and its updates aren't automatic either. Your deployment panel is in the same position. Dokploy and Coolify both published critical advisories in 2026, and Ubuntu's tools won't mention them.

Check apt list --upgradable for what's pending, and subscribe to the security advisories of anything else you run.

What About CVE-2026-98432 and the Other Recent Flaws?

Here is where three recent ones stood for Ubuntu 24.04 on November 5, 2026:

CVE-2026-98432 is the one to watch. The newest kernel in the 24.04 repositories on my test machine was 6.8.0-147.147, one that the tracker doesn't list as fixed, and pro fix reported this:

1 affected source package is installed: linux
(1/1) linux:
A fix is coming soon. Try again tomorrow.

1 package is still affected: linux
✘ CVE-2026-98432 is not resolved.

The tracker page lists a community-submitted nftables workaround, which isn't an official fix. It says the rule reduces the risk without fully preventing exploitation, that it breaks TCP connections relying on IPv4 options, and that containers with separate networking need their own rule. Read it there and test it before applying it, because the details may change.

CVE-2026-109518 needs an attacker who can tamper with your HTTP traffic to the archive, such as a malicious mirror or proxy, and a client with retries enabled, which is the default from 22.04 on. Ubuntu's default sources use http:// with signed metadata, as mine did, so don't assume the signature check alone covered you here. The tracker shows releases from 20.04 back get the fix only through Ubuntu Pro.

CVE-2026-31431, known as Copy Fail, is a good test of whether your reboots happen. Canonical's guidance is to upgrade the kernel and reboot, and it warns that the flaw may enable container escape on hosts running untrusted workloads. If uname -r shows a standard 24.04 kernel older than 6.8.0-117, you've been missing reboots for months. Other kernel variants have their own fixed versions on the tracker, such as 6.17.0-29.29~24.04.1 for the HWE kernel.

What Should You Do When a New CVE Drops?

Work through the same order each time:

1. Run sudo pro fix CVE-ID --dry-run to find the package and whether a fix exists.
2. Decide how exposed you are. A local flaw needs an attacker on the box, while a remote one in TCP or SSH doesn't.
3. If a fix exists, install it now rather than waiting for the morning timer.
4. If it's the kernel, reboot, then confirm with uname -r.
5. If it's a library, check your images too, and rebuild them.
6. If no fix exists yet, close unused ports at your provider firewall, then check again tomorrow.

Summary

pro fix gives you the fastest answer, and the tracker gives you the version to compare against. The mistakes are in the gaps around them: a patched kernel that was never rebooted, a container image built months ago, and third-party packages like Docker that Ubuntu doesn't update.

Check those three whenever a serious CVE lands.

The rest of the list is in my Ubuntu server hardening checklist, and my self-hosting course includes a maintenance routine for a server you run yourself.

Thanks for reading.

And stay awesome!