The APT Flaw in Debian and Ubuntu and How to Close It

On November 4, 2026, Debian, Canonical and the APT maintainers released fixed versions of APT, the package manager behind apt and apt-get on Debian, Ubuntu and the distributions built on them. The flaw they close is CVE-2026-109518, found by Max Justicz. In the right conditions it let an attacker who could tamper with the HTTP traffic between a server and its package mirror slip an unverified package into an upgrade. Packages install as root, so the result is code running as root.

The fix is one package update, and on Ubuntu servers with unattended upgrades it has probably installed itself already. It is still worth five minutes to confirm, because the default settings on Debian 12, Ubuntu 22.04 and every release since meet both conditions the bug needs, and because the update itself runs through the old APT. This article covers who is exposed, a one-line check, the way Canonical recommends installing the fix, and what to change in Docker builds while the Ubuntu base images catch up.

Where the Fix Stands on November 9

We pulled fresh Debian and Ubuntu images on November 9 and ran apt-cache policy apt in each. Every fixed version above for Debian 12, Debian 13 and Ubuntu 22.04, 24.04 and 26.04 was in the security pocket and installable. Canonical rates the flaw High, with a CVSS 4.0 score of 7.7, and the APT maintainer's announcement calls it critical. None of the advisories from Debian, Canonical or the APT project mentions attacks in the wild, and the flaw was not in CISA's catalogue of exploited vulnerabilities as of November 6.

What Goes Wrong, in Plain Terms

APT does not trust the network, and that is why plain HTTP mirrors have been acceptable for so long. The release file a mirror serves is signed with the distribution's key. That file lists the checksums of the package indexes, and the indexes list the checksum of every package. A package that does not match its checksum is refused, whoever served it.

The flaw is in how APT writes downloaded files to disk, not in that chain of signatures. According to Julian Andres Klode, the APT maintainer who announced the fix, a redirect combined with a temporary server error that makes APT retry a download could cause APT to overwrite an existing hard link with a payload the attacker chose. Debian's advisory describes it as APT merging two different package downloads after an HTTP redirect gives them the same address. The upshot is that a file could change after it had been checked. The fix gives a resumed download its own new file instead of reusing the linked one, and it does not change how signatures or checksums are verified.

Two things have to be true for an attack to work. The attacker must be able to manipulate the HTTP traffic, either from a position on the network path or by running the mirror itself. And APT must be set to retry failed downloads through the Acquire::Retries setting. Retries have been on by default, set to 3, since APT 2.3.2, which is why Debian 12 and Ubuntu 22.04 are the first releases affected out of the box. On older releases the bug only matters if somebody set retries by hand, which deployment scripts sometimes do.

Who Is Actually Exposed

The default package sources on Debian and Ubuntu use http://. Every image we checked, Debian 12 and 13 and Ubuntu 22.04, 24.04 and 26.04, pointed at http:// mirrors, so the first condition is met almost everywhere and the question becomes who could sit in the path.

For a server in a data centre talking to its distribution's mirror, that is a short and well-guarded list, and the practical risk is low. It grows in a few common setups. A shared office or build network, a caching proxy such as apt-cacher-ng that many machines pull through, an internal mirror that a lot of servers trust, or a third-party mirror chosen for speed all put more parties between the server and the packages. Laptops and workstations on public networks are the clearest case, though this article is about servers.

Snap packages are not affected, because snaps are delivered by a different system. Canonical also notes that unattended-upgrades, enabled by default since Ubuntu 16.04, installs security fixes within 24 hours of release. Many Ubuntu servers will therefore have the fixed APT already, but a disabled timer, a held package or a pinned mirror can stop that quietly, so check rather than assume.

Check Your Servers

Canonical's suggested check lists the installed packages built from the APT source package, which covers both apt and libapt-pkg.

apt list --installed '?source-package(^apt$)'

Compare the version with the table above. On a patched Debian 12 server the output shows 2.6.2 from oldstable-security. On an unpatched Ubuntu 22.04 it shows 2.4.14 with upgradable to: 2.4.15ubuntu0.1 next to it, which is what we saw in the stock image.

Two more lines tell you how exposed a server was while it waited.

apt-config dump | grep -i 'Acquire::Retries'
grep -rhE '^(URIs:|deb )' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

An empty result from the first command does not mean retries are off. The default of 3 is built into APT and only appears in the dump when a configuration file sets it, so on Debian 12, Ubuntu 22.04 and later, no output means 3. The second command lists the mirrors, and any http:// line is one where the network path matters.

Install the Fix Safely

The upgrade that brings the fixed APT is downloaded by the old APT. Canonical's guidance is to switch retries off for that one run, which removes the condition the attack needs, using a command-line option that changes no configuration file.

To upgrade everything at once:

sudo apt update && sudo apt upgrade -o Acquire::Retries=0

To upgrade only APT, for example on a server where a full upgrade needs a maintenance window:

sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)'

We ran the second command in an Ubuntu 24.04 container and it moved APT from 2.8.3 to 2.8.4ubuntu0.1 in one step. Run the check from the previous section afterwards. Once the fixed APT is installed, retries can stay at their default, since the fix is in how the files are written. Canonical makes the same point about mirrors. After the client is updated, even a compromised mirror can no longer use this flaw.

Move Your Mirrors to HTTPS

Fetching packages over HTTPS takes the on-path attacker out of the picture, because the traffic can no longer be changed in transit. Canonical describes it as a mitigation rather than a fix, and it does not help against a mirror that is itself malicious, so it belongs after the update, not instead of it. As general hardening it is cheap, and both main mirrors support it.

For Ubuntu, Canonical publishes this command, which covers the main archive, the security archive, ports and country mirrors.

sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
sudo apt update

For Debian on deb.debian.org, make sure ca-certificates is installed, then change the scheme in whichever files hold the mirror.

sudo sed -i 's#http://deb.debian.org#https://deb.debian.org#g' $(grep -rl 'http://deb.debian.org' /etc/apt/sources.list /etc/apt/sources.list.d/)
sudo apt update

We ran both on clean containers and apt update then fetched every index over HTTPS. On Ubuntu 24.04 and later the sed command prints an error for *.list, because that release keeps its sources in ubuntu.sources and the pattern matches nothing. The error is harmless and the other files are still changed. A third-party or internal mirror may not offer HTTPS, so read the output of apt update for errors before moving on. Neither command touches other mirror hosts, so check those by hand.

Docker Images and CI Builds

Containers deserve a separate look, because a running container rarely runs apt, while the build that produced it does. When we pulled the official images on November 9, debian:12 and debian:13 already carried the fixed APT. The Ubuntu images did not. ubuntu:22.04 had APT 2.4.14, ubuntu:24.04 had 2.8.3 and ubuntu:26.04 had 3.2.0, all affected and all pointed at http:// mirrors.

Every apt-get install in a Dockerfile built on those images therefore runs the vulnerable APT on whatever network the build runner sits on. Until the base images are refreshed, add the same option to the install and upgrade lines.

FROM ubuntu:24.04
RUN apt-get update \
 && apt-get install -y --no-install-recommends -o Acquire::Retries=0 curl ca-certificates \
 && rm -rf /var/lib/apt/lists/*

Once Canonical publishes refreshed images, rebuild from them and the option can go. Images you built before November 4 contain the old APT too, but that only matters if something inside them runs apt at runtime, which is worth avoiding anyway.

Ubuntu 20.04 and Older

Servers on Ubuntu 20.04 or 18.04 are not affected in a default setup, because their APT predates the retries default. They are affected if a script or configuration file set Acquire::Retries, and the first command in the check section shows whether one did. The fixed packages for these releases come only through Ubuntu Pro, which Canonical offers free for up to five machines.

The larger point is that 20.04 left standard support in May 2025. A flaw like this one is a reminder that an old release stops getting free fixes for the parts of the system everyone takes for granted, the package manager included. Debian 11 is in the same position since its free long-term support ended on August 31, 2026. If those servers are still in production, an upgrade plan is worth more than any single patch.

What This Means for Your Team

For most teams this is a short job. Check the APT version on each Debian and Ubuntu server, install the fix with retries switched off for that run, and add the same option to Dockerfiles built on Ubuntu until the base images are refreshed. Moving mirrors to HTTPS is a sensible follow-up while you are in there.

It is the third Linux security fix we have covered this month, after the kernel TCP flaw CVE-2026-98432, which also reaches nearly every server, and the narrower OpenSSH bypass on Alpine. Teams that would rather not chase these one at a time can hand the routine patching and the checks to us as part of our servers management work.

Sources

• Debian security tracker, CVE-2026-109518
• DSA-6607-1, apt security update for Debian 13
• Ubuntu CVE page for CVE-2026-109518
• USN-8996-1, APT vulnerability
• Canonical, APT vulnerability fixes available
• Julian Andres Klode's announcement on the deity list
• The APT fix commit
• Ubuntu archive verification documentation