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

> Check an Ubuntu CVE with pro fix, compare versions against the tracker, and confirm the running kernel. Includes CVE-2026-98432, the APT flaw, and Copy Fail.

Published: 2026-11-05. Author: Milan Jovanović.

Canonical: https://milanjovanovic.tech/blog/check-ubuntu-server-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:

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

```text
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:

| pro fix says | Meaning | What to do |
| --- | --- | --- |
| A fix is available in Ubuntu standard updates | You are exposed and the patch exists | Run it without --dry-run, or wait for unattended upgrades |
| A fix is coming soon. Try again tomorrow. | You are exposed and no patch has shipped | Reduce exposure and check again daily |
| The update is already installed. A reboot is required | The fix is on disk but not running | Reboot |
| The update is already installed, is resolved | The package is patched | For a kernel flaw, still check uname -r |

## How Do You Compare Versions by Hand?

Use the [**Ubuntu CVE tracker**](https://ubuntu.com/security/cves), and compare with `dpkg`, because these version strings don't sort the way they look:

```bash
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:

```bash
apt-get changelog apt | head -6
```

```text
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:

```bash
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:

```text
(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**](https://milanjovanovic.tech/blog/unattended-upgrades-ubuntu), 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:

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

```text
2.8.4ubuntu0.1
2.8.3
```

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

```bash
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**](https://www.docker.com/blog/trivy-supply-chain-compromise-what-docker-hub-users-should-know/), 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:

```text
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**](https://milanjovanovic.tech/blog/unattended-upgrades-ubuntu) either.
Your deployment panel is in the same position.
[**Dokploy and Coolify**](https://milanjovanovic.tech/blog/dokploy-vs-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 | What it is | Ubuntu priority | Status on 24.04 | What to do |
| --- | --- | --- | --- | --- |
| CVE-2026-98432 | Kernel IPv4 TCP flaw that can lead to remote code execution, CVSS 9.8 | Critical | Vulnerable, fix in progress in 6.8.0-149.149 | Install and reboot as soon as it ships |
| CVE-2026-109518 | APT flaw that lets an on-path attacker get an unverified package installed, published November 4 | High | Fixed in 2.8.4ubuntu0.1 | Update apt, unattended upgrades should pick it up |
| CVE-2026-31431, Copy Fail | Kernel local privilege escalation, may allow container escape | High | Fixed in 6.8.0-117.117 | Confirm you are running that kernel or newer |

**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:

```text
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**](https://ubuntu.com/security/CVE-2026-98432) 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**](https://ubuntu.com/security/CVE-2026-109518) 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**](https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available) 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**](https://milanjovanovic.tech/blog/cloud-firewall-vs-ufw), 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**](https://milanjovanovic.tech/blog/ubuntu-server-hardening), and my [**self-hosting course**](https://milanjovanovic.tech/pragmatic-self-hosting) includes a maintenance routine for a server you run yourself.

Thanks for reading.

And stay awesome!

---

## Frequently asked questions

### How do I check if my Ubuntu server is affected by a CVE?

Run pro fix with the CVE ID and the dry-run option. It names the affected package, says whether a fix exists, and reports whether a reboot is needed. Then compare your installed version with the fixed version on the Ubuntu CVE tracker. You do not need an Ubuntu Pro subscription for fixes in the standard repositories.

### Is my Ubuntu server affected by CVE-2026-98432?

Probably, until a fixed kernel ships. On November 5, 2026, the Ubuntu tracker listed 22.04, 24.04, and 26.04 as vulnerable with fixes in progress, and pro fix on 24.04 reported that a fix is coming soon. Check the tracker for the current status, then install the kernel and reboot when it arrives.

### Why does my scanner say OpenSSH is vulnerable after updating Ubuntu?

Ubuntu backports security fixes without changing the upstream version number. A package such as 1:9.6p1-3ubuntu13.20 still reports OpenSSH 9.6, so a scanner that reads only the banner can flag fixes you already have. Compare the full package version with the Ubuntu tracker.

### Do I need to reboot after a kernel security update?

Yes. Installing the package does not change the running kernel. Compare uname -r with the installed kernels, and check /var/run/reboot-required. Ubuntu Livepatch can patch some critical and high severity kernel flaws without a reboot, but Canonical says it does not replace rebooting.

### Does updating the host fix CVEs inside Docker containers?

It fixes the kernel, because containers share it. It does not fix packages inside images. In testing, the host had the patched apt package while a container from the ubuntu:24.04 image still had the older one. Rebuild your images with a fresh base and redeploy.