APT Flaw CVE-2026-109518: How to Patch Debian and Ubuntu

X (Twitter) Facebook Pinterest LinkedIn E-mail

Debian and Ubuntu released new versions of APT (Advanced Package Tool, the package manager used by both distributions) on November 4, 2026, to close CVE-2026-109518, a flaw that lets an attacker positioned between the server and the repository slip in a tampered package and install it with root privileges. The bug requires specific network conditions, but it touches the very tool used to update everything else, which makes it a good test of how companies patch their Linux fleets, virtual machine images, and containers.

The APT flaw in Debian and Ubuntu in 30 seconds

Debian and Ubuntu released APT versions on 04/11/2026 that fix CVE-2026-109518, discovered by Max Justicz.
An attacker positioned in the HTTP traffic, or a malicious mirror or proxy, can swap an already-verified package and execute code as root.
It requires redirects and download retries, which have been enabled by default since Debian 12 and Ubuntu 22.04.
Canonical scores it 7.7 on CVSS 4.0, and there is no known exploitation or public proof of concept.

The case has been detailed by OpenSecurity, which cites advisory APT-2026-11-01 from Julian Andres Klode, APT’s maintainer and author of the fix for all stable branches. The discoverer is Max Justicz, the same researcher who found CVE-2019-3462 back in 2019, another APT flaw related to download tampering. The CVE (Common Vulnerabilities and Exposures, the public vulnerability catalog) was registered by Canonical as a CNA (CVE Numbering Authority, an entity authorized to assign identifiers).

The problem sits in APT’s HTTP component. When a redirect causes two separate downloads to end up pointing at the same URI, APT can merge them. If a download is interrupted and resumed, hard-link reuse allows the package to be swapped out after its signature has already been checked. It’s a TOCTOU (time-of-check to time-of-use) race condition. Since the scripts in a .deb package run with administrator privileges, the result can be code execution as root.

What an attacker needs, and which versions fix it

The flaw can’t be exploited from just anywhere on the internet. It requires a MITM (man-in-the-middle) attack: the attacker must control the HTTP path between the machine and the repository, whether on the same network, through a compromised proxy, or sitting in front of a mirror. The server also has to be installing or updating packages at that moment, the attacker must be able to force redirects and transient errors, and APT has to retry the downloads.

That last point explains why it mainly affects more recent systems. The Acquire::Retries option has defaulted to 3 since APT 2.3.2, the version that shipped with Debian 12 and Ubuntu 22.04. Earlier versions aren’t exposed under their default configuration, though many administrators turned retries on manually to deal with unstable mirrors — which is why the fixes have also been backported to older branches.

Canonical rates the flaw 7.7 out of 10 on CVSS 4.0 (Common Vulnerability Scoring System), which corresponds to high severity, and gives it high priority in Ubuntu. Klode calls it critical in his advisory. As of November 5, there is no known active exploitation or public proof of concept. According to Canonical, the flaw affects any APT-based interface (apt, apt-get, aptitude, or Ubuntu’s graphical tools), but not snap package installation. The same update fixes several out-of-bounds memory accesses that, according to Klode, allow at most a denial of service in services such as PackageKit.

System	Fixed APT version	Advisory
Debian 12 bookworm	2.6.2	DLA-4880-1
Debian 13 trixie	3.0.4	DSA-6607-1
Debian sid	3.3.6	No dedicated advisory
Debian forky (testing)	Pending (3.3.5 vulnerable)	Will arrive from sid
Ubuntu 26.10	3.3.3ubuntu0.1	USN-8996-1
Ubuntu 26.04 LTS	3.2.1ubuntu0.1	USN-8996-1
Ubuntu 24.04 LTS	2.8.4ubuntu0.1	USN-8996-1
Ubuntu 22.04 LTS	2.4.15ubuntu0.1	USN-8996-1
Ubuntu 20.04 LTS	2.0.12+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 18.04 LTS	1.6.19+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 16.04 LTS	1.2.36+esm1 (Ubuntu Pro)	USN-8996-1
Ubuntu 14.04 LTS	1.0.1ubuntu2.24+esm4 (Ubuntu Pro)	USN-8996-1

Debian 11 and Debian 10 only get the fix through Extended LTS (ELTS), the paid extended-support program, and the APT project has also published the 2.2.5 and 1.8.2.4 branches. Derivative distributions that build their own APT need to ship their own updates.

To check the installed version and update only the affected package, Canonical recommends disabling retries during the update itself, so the patch can’t be attacked while it’s being downloaded:

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

Fleets, templates, and images: where APT falls behind

At a company with dozens or hundreds of servers, the patch doesn’t apply once — it has to be applied everywhere APT lives. Running servers are the easy part. According to Canonical, unattended-upgrades has been enabled by default since Ubuntu 16.04 and applies security updates every 24 hours, so machines with that setting intact should already have the fix. The Debian wiki explains that the default configuration installs security updates, not new features, though the package may not be installed or may be disabled. It’s worth checking with sudo unattended-upgrade -d and reviewing the logs in /var/log/unattended-upgrades/, since a stopped service doesn’t raise an alarm.

Maintenance windows are still needed for whatever can’t be applied live, but this case doesn’t require a reboot. Livepatch doesn’t come into play either: Canonical makes clear that its live-patching service covers only the kernel, and that userspace libraries and programs are handled by unattended-upgrades or a management tool such as Landscape. Livepatch cuts down on reboots caused by kernel bugs — it doesn’t replace package updates.

The weak spot is usually whatever isn’t running yet. Virtual machine templates, cloud providers’ golden images, and base container images carry whatever APT version they had on the day they were built. A container built today on an unpatched Debian 12 or Ubuntu 22.04 base drags along a vulnerable APT — and it’s precisely during the build that it installs packages, often through the CI pipeline’s own proxy or mirror. That’s why those images need to be rebuilt with an updated base, their APT version checked, and the ones that shouldn’t be used anymore removed from the registry.

Older versions and Ubuntu Pro

Ubuntu branches outside standard support depend on Ubuntu Pro. According to Canonical, Ubuntu 20.04 and 18.04 get the patches through ESM (Expanded Security Maintenance), while 16.04 and 14.04 also need the Legacy add-on. Ubuntu Pro is free for up to five machines for personal use. In practice, a company still running 18.04 servers without a subscription won’t receive this fix, and the same goes for Debian 10 or 11 without ELTS.

Mirrors, proxies, and the package supply chain

Many organizations don’t download packages directly from the official repositories. They use internal mirrors, caches such as apt-cacher-ng, or corporate proxies to save bandwidth and control what reaches production. That middle piece is exactly the kind of position this attack needs. Repository signing protects end-to-end integrity, but here the package is swapped after it’s been verified, so relying on the signature alone isn’t enough while APT remains unpatched.

Canonical notes that encrypting traffic with HTTPS prevents a man-in-the-middle attacker from tampering with downloads, and suggests switching APT sources to HTTPS wherever that risk can’t be ruled out. It warns that some community mirrors don’t support HTTPS. OpenSecurity adds the caveat that HTTPS doesn’t help if the trusted mirror or proxy itself is the one that’s compromised. Once the patched APT is installed, according to Canonical, a compromised mirror no longer poses a risk for this particular flaw.

As a temporary measure on systems that can’t yet be updated, OpenSecurity suggests setting Acquire::Retries to 0 and removing that setting once the patch is applied, along with checking which sources are still using HTTP:

echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-cve-2026-109518
grep -rn "http://" /etc/apt/sources.list /etc/apt/sources.list.d/

Inventory: knowing what’s patched and what isn’t

Responding to an advisory like this one means knowing which APT version is running on every server, template, and image. For Debian, the Debian Security Tracker shows the status of each CVE by distribution version. For Ubuntu, Canonical publishes USNs (Ubuntu Security Notices) and OVAL (Open Vulnerability and Assessment Language) data in machine-readable form, which SCAP-compatible tools such as OpenSCAP can use to audit a system or an official cloud image from its manifest:

wget https://security-metadata.canonical.com/oval/com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
bunzip2 com.ubuntu.$(lsb_release -cs).usn.oval.xml.bz2
oscap oval eval --report report.html com.ubuntu.$(lsb_release -cs).usn.oval.xml

Pressure on patching timelines isn’t new. Revista Cloud has already covered how a flaw in libssh2 raised remote-execution concerns over SSH packets earlier this year, and in October it looked at which distributions and panels had fixed PHP2Shell. In the case of APT, the practical risk is narrower than in other recent flaws, but it affects the very mechanism that distributes every other fix.

Frequently asked questions

Which Debian and Ubuntu versions are exposed to CVE-2026-109518 by default?

Those running APT 2.3.2 or later with Acquire::Retries set to 3: Debian 12, Debian 13, and Ubuntu 22.04 onward. Older versions are only exposed if someone manually enabled retries.

Is using HTTPS repositories enough to avoid the flaw?

According to Canonical, TLS prevents a man-in-the-middle attacker from tampering with traffic. OpenSecurity warns that it doesn’t help if the mirror or proxy itself is compromised, so the full fix is installing the patched version of APT.

Do container and virtual machine images need to be rebuilt?

Yes, if they’re based on an image with a vulnerable APT and will install packages. Updating running servers doesn’t change the templates or images already stored in the registry.

How is APT updated on Ubuntu 20.04 or earlier?

Those branches get the fix as +esm packages through Ubuntu Pro, which is free for personal use on up to five machines. On Debian 11 and 10, the patch arrives through the paid Extended LTS program.

This article is also available in Spanish: «El fallo de APT en Debian y Ubuntu pone a prueba cómo se parchea Linux en la nube», on revistacloud.com.

Sources: