APT Vulnerability CVE-2026-109518: How a Retried Download Can Hand an Attacker Root

A new APT vulnerability, tracked as CVE-2026-109518, lets someone who can tamper with your package downloads swap a verified package for their own. The replacement then installs and runs as root. Debian, Ubuntu and the APT developers published advisories on 4 November 2026, and the APT developers call the flaw critical.

APT is the package manager behind Debian, Ubuntu and the many distributions built on them. It sits in the update routine of a huge number of UK servers, build agents and containers. So a bug in how it checks downloads deserves attention even without reports of attacks.

What the APT vulnerability actually does

APT normally checks each package against signed metadata before it installs anything. This flaw lets an attacker get around that check. The reporter was Max Justicz, and the advisories describe the cause as hard link reuse.

The attacker needs to sit on the network path between the client and the archive server. Ubuntu gives a malicious mirror or proxy as examples. From there, they use HTTP redirects and ordinary temporary server errors to make APT retry a download. On the retry, the attacker can overwrite an existing hard link with a payload of their choosing.

The Debian advisory puts the result plainly: a remote attacker “could bypass verification of downloaded packages”. Because .deb files install with root privileges, that means potential remote code execution as root.

Who is exposed to this APT vulnerability

The attack depends on APT retrying failed downloads, which is controlled by the Acquire::Retries setting. A non-zero value is needed. Ubuntu says the default of 3 applies from Debian 12 and Ubuntu 22.04 LTS onward. The Debian advisory notes that the setting has only been the default since APT 2.3.2, and warns that older user scripts may have switched it on.

That detail matters for anyone running older fleets. Ubuntu says Debian 11 and Ubuntu 20.04 are not affected in a default configuration. But a configuration management script that sets retries on an old build host would put that host back in scope.

Ubuntu rates the flaw high priority with a CVSS 4.0 score of 7.7. The vector shows a network attack that needs some user interaction, with high impact on confidentiality, integrity and availability. In plain terms, it is not a drive-by bug. It needs a bad position on the network and an update or install in progress.

Fixed versions for the APT vulnerability

Fixes are out for Debian and Ubuntu. Ubuntu lists these builds:

• Ubuntu 26.10: 3.3.3ubuntu0.1
• Ubuntu 26.04 LTS: 3.2.1ubuntu0.1
• Ubuntu 24.04 LTS: 2.8.4ubuntu0.1
• Ubuntu 22.04 LTS: 2.4.15ubuntu0.1

Older Ubuntu releases get fixes through Ubuntu Pro or the Legacy Support add-on. On the Debian side, the tracker lists 2.6.2 for bookworm and 3.0.4 for trixie. Debian unstable has 3.3.6, while the tracker did not list a fix for forky at the time of writing.

The Hacker News reported that none of the advisories describe exploitation in the wild, and none offer a workaround for systems that cannot update yet. The advisories also describe the attack over HTTP. They do not say whether HTTPS package sources are exposed, so treat that as an open question rather than an assumption either way.

What it means for a UK business

The realistic attacker for this APT vulnerability is not a stranger on the internet. It is someone who already controls a hop in your update path. That could be a compromised internal mirror, a caching proxy, a hostile network at a remote site, or a supplier-managed repository.

That makes the bug a good example of why privilege escalation and trust in the update chain belong in a security review. Teams often trust the package manager completely. This flaw shows what happens when one assumption inside it breaks.

It also repeats an old pattern. Max Justicz found an earlier APT flaw, CVE-2019-3462, that let a man in the middle run code as root on a machine and install any package. Update tooling is a recurring target because it runs with high privilege and talks to the network.

What to do this week

1. Patch APT on every Debian and Ubuntu host, starting with build servers, jump hosts and anything that pulls from internal mirrors.
2. Search your configuration management for Acquire::Retries on older releases, since a script may have enabled it.
3. Check which of your mirrors and proxies serve plain HTTP, and who can alter traffic on those paths.
4. Confirm that the patch actually landed. Our earlier piece on Linux kernel patching shows how often a fix ships and then sits unapplied for weeks.

A penetration test of your build and update infrastructure can answer the harder question: who could sit in that path today, and what would they reach if they did.

Exploiting the APT vulnerability needs no exotic skill once the attacker holds the right position. The hard part is getting there, and many organisations have never mapped who could.