APT Vulnerability in Debian and Ubuntu: How a MitM Attack Substitutes Verified Packages and Runs Code as Root

On November 4, 2026, Debian developers, Canonical (Ubuntu), and the APT team itself simultaneously published notices about CVE-2026-109518 in the APT package manager — the foundation of software updates for Debian, Ubuntu, and all their derivative distributions. This is one of those vulnerabilities that strike at the very foundation of trust in Linux systems: it lets an attacker who controls network traffic between a server and a package mirror substitute an already-verified package with their own — and this substituted code runs with root privileges.

The vulnerability was discovered by researcher Max Justicz, who described his process on X briefly and tellingly: "I used AI for two hours and found a zero-day that would let a state hack any server on ordinary Ubuntu." Ubuntu rated the vulnerability High with a CVSS 4.0 score of 7.7, while the APT developers themselves call it critical. Importantly, at the time of publication neither Debian nor Canonical reported any real-world exploitation — but that's no reason to postpone updates.

The essence of the vulnerability: hard links and re-downloads

APT is a tool administrators trust unconditionally: when you run apt install, the manager downloads packages from a repository, verifies their digital signatures, and only then installs them. Installation happens with root privileges, because package installation runs so-called maintainer scripts — service scripts that configure the system after files are unpacked.

The problem lies in two mechanisms that normally work invisibly. The first is HTTP redirect handling: when a mirror redirects a request, APT can "merge" two downloads of different packages if they end up at the same address. The second is retries: if a server temporarily doesn't respond or returns an error, APT repeats the download. During that retry, the file is reused via a hard link, and that's exactly where an attacker can swap in content after the package has already passed signature verification.

MITRE classifies the vulnerability under two weaknesses: CWE-62 (UNIX hard link) and CWE-367 — a time-of-check/time-of-use (TOCTOU) race. A classic pattern where the system checks one file but later uses a different one.

To understand why this is serious, recall how APT verifies packages. The manager doesn't sign each .deb individually: the repository holds a GPG-signed Release file listing checksums of all packages. APT compares the downloaded file against those sums, and only if they match does it consider the package "verified." This vulnerability allows substituting the file after that match is confirmed — meaning the "verified" label gets attached to entirely different, attacker-controlled content.

How the attack works

The main requirement for the attacker is the ability to modify HTTP traffic between APT and the package server. This could be a machine on the network path, a malicious repository mirror, or a compromised proxy server. The attack unfolds like this:

1. The attacker uses HTTP redirects to make two different package downloads get the same address — APT starts treating them as the same file.
2. Ordinary temporary server errors (for example, 500 or 503) force APT to retry the download.
3. During the retry, APT reuses the file via a hard link, and the attacker substitutes their own package in place of the already-verified one.
4. The package installs, its maintainer scripts run as root — the attacker gains full control of the system.

The key precondition is that Acquire::Retries must be greater than zero. The default value of 3 has been set since Debian 12 (Bookworm) and Ubuntu 22.04 LTS. That's why older releases aren't vulnerable in their default configuration — but APT developers warn that many scripts, images, and configuration-management systems enable retries manually even on old versions.

Who's at risk

The list of vulnerable systems is long precisely because APT is a shared foundation:

• Debian 12 (Bookworm) and Debian 13 (Trixie) in default configuration.
• Debian testing (Forky) — at disclosure still running the vulnerable APT 3.3.5.
• Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS, and 26.10.
• Derivative distributions — Ubuntu explicitly notes that builds based on Debian/Ubuntu are also vulnerable, without naming specific ones.
• Debian 11 (Bullseye) and Ubuntu 20.04 and older — only if retries are enabled manually.

Amazon emphasized a separate aspect: the vulnerability affects Amazon EC2 instances on Ubuntu/Debian and container images based on them. For containers this is especially unpleasant, because the image has to be "re-baked" manually across the whole pipeline.

An important detail: the notices describe an attack via HTTP package sources. The fact that many installations still use unencrypted HTTP mirrors for internal repositories widens the real attack surface.

What's already fixed

Patches came out the same day, November 4, 2026. Ubuntu released updates in bulletin USN-8996-1:

• Ubuntu 26.10 → apt 3.3.3ubuntu0.1
• Ubuntu 26.04 LTS → apt 3.2.1ubuntu0.1
• Ubuntu 24.04 LTS → apt 2.8.4ubuntu0.1
• Ubuntu 22.04 LTS → apt 2.4.15ubuntu0.1
• Older LTS (20.04 and below) — only via Ubuntu Pro subscription (e.g., 20.04 → 2.0.12+esm1)

Debian closed the issue with two bulletins: DSA-6607-1 for Trixie (apt 3.0.4) and DLA-4880-1 for Bookworm (apt 2.6.2). For Debian unstable, the fix came in version 3.3.6. Separately, APT developers published the fixed 2.2.5 package for Debian 11 (Bullseye), whose long-term support ended on August 31, 2026.

The fix itself, prepared by APT developer Julian Andres Klode as early as October 12, changes the download code so the destination file is opened exclusively and existing files are deleted before copying partially downloaded content. This removes the very possibility of "merging" two downloads via a hard link.

Context: not the first find by the same researcher

For Max Justicz this is already the second vulnerability found specifically in APT. In January 2019 he discovered CVE-2019-3462 — then the HTTP redirect handler didn't properly "clean" fields passed over the network, and a man-in-the-middle attacker could inject malicious content that APT treated as a valid package and installed with root privileges. Back then too, the advice was to temporarily disable redirects: apt -o Acquire::http::AllowRedirect=false update.

The similarity of symptoms is telling: seven years ago and now, the problem lay not in a specific package but in APT's transport layer itself — in how the manager trusts data arriving over the network before verifying it against the signed manifest. That's why such bugs are fixed immediately and bulletins published the same day.

How to check you're already protected

After updating, don't take it on faith — check the actual package version with the command apt-cache policy apt.

Expected fixed versions: Ubuntu 22.04 LTS — 2.4.15ubuntu0.1, Ubuntu 24.04 LTS — 2.8.4ubuntu0.1, Ubuntu 26.04 LTS — 3.2.1ubuntu0.1, Ubuntu 26.10 — 3.3.3ubuntu0.1; Debian Bookworm — 2.6.2, Debian Trixie — 3.0.4, Debian unstable — 3.3.6. If you see a lower version in the same branch, the system is still vulnerable and the update didn't install (for example, no access to the security repository).

Pay special attention to old systems. Debian 11 (Bullseye) and Ubuntu 20.04 and below aren't in the default vulnerable list, but if Acquire::Retries is manually enabled on them, they're at risk too. Fixes exist for them (Bullseye — apt 2.2.5, Ubuntu 20.04 — via Ubuntu Pro), but it's more reliable to plan a migration to a supported release.

How to protect yourself

1. Update APT immediately. The basic commands: sudo apt-get update && sudo apt-get upgrade. If you have a large fleet of servers or containers, run the update through your standard configuration-management system (Ansible, Puppet, etc.) and verify the apt package was replaced with a fixed version from the list above.
2. Temporary mitigation before updating. If you can't update right now, disable retries: echo 'Acquire::Retries "0";' | sudo tee /etc/apt/apt.conf.d/99-no-retries. This isn't a fix — it only removes one of the two attack conditions, and on an unstable connection it may make updates less reliable. After installing the patch, be sure to restore the value or delete the file.
3. Use HTTPS mirrors. If your sources.list still points at http://, switch to encrypted https:// mirrors — this lowers the risk of traffic interception on the network path.
4. Rebuild container images. For Docker/Kubernetes, rebuild base images with the fixed APT and run a vulnerability scan against your registry — old images can "sleep" for months, waiting to be redeployed.
5. Update legacy systems. Debian 11 (Bullseye) is already out of long-term support; if such machines are still running — plan a migration rather than relying on individual developer "patches."
6. Raise team awareness. This vulnerability is a great example of why basic update hygiene and understanding the supply chain matter more than any single patch. You can start with our "Cybersecurity: learning" material.

Conclusion

CVE-2026-109518 strikes where most administrators feel completely safe — the package manager. It requires neither a user error nor a complex exploit: it's enough to be on the network path or control a proxy/mirror, and a verified package can be substituted "on the fly." That's why it's called critical despite the comparatively "modest" CVSS score.

The good news is that the attack mechanism requires two conditions at once (redirects plus retries), and patches are already available for all current releases. No real-world exploitation has been recorded, but that's no guarantee for the future: as practice shows, public disclosure of such vulnerabilities usually starts a race between updating administrators and attackers writing an exploit.

The main lesson goes beyond one package. Trust in tools we use "on autopilot" must be regularly re-verified — and in APT's case, that check has once again confirmed: timely updates and encrypted package-delivery channels remain the two cheapest and most effective lines of defense for any Linux infrastructure.