An APT flaw lets an on-path attacker swap a verified package and run code as root on Debian and Ubuntu

November 4, 2026. Debian publishes DSA-6607-1 and DLA-4880-1 to fix CVE-2026-109518, a critical flaw in APT, the package manager shared by Debian, Ubuntu, and their derivatives. November 4, 2026, 14:25 UTC. Ubuntu follows with four fixes in its security archive. November 4, 2026, 15:46 UTC. Ubuntu still lists all eight releases it tracks — from 14.04 LTS to 26.10 — as vulnerable while the updates propagate. The flaw boils down to one sentence: an attacker who can tamper with HTTP traffic between a host and its package mirror can swap an already-verified package for their own, and that code then runs as root.

For a Debian or Ubuntu fleet that installs through a proxy or mirror you do not control, this is not a hygiene footnote. It is full compromise triggered by an ordinary package install.

The mechanics: retry breaks the check

The heart of the flaw is in how APT handles failed downloads. Since Debian 12 and Ubuntu 22.04, APT retries failed downloads by default, a behavior driven by the Acquire::Retries setting. That behavior, meant to make installs more robust, opens a window: during a retry, APT reuses some already-validated state without re-checking what it receives.

In practice, the attacker — a malicious mirror, a compromised proxy, or anyone on-path along the HTTP route — combines HTTP redirects with ordinary temporary server errors to force APT to retry. At the moment of the retry, they substitute the legitimate package with a malicious one. APT installs it as if it had passed signature verification, and the payload — typically a postinst script — runs with root privileges.

The entry point is easy for an operator to grasp: HTTP traffic is plaintext by default on most Debian and Ubuntu setups. Official repositories are reachable over HTTP, and GPG package signing is exactly what is supposed to compensate for the lack of encryption. The flaw sidesteps that compensation: it does not need to break a key, it exploits the moment APT skips the re-check.

# Check the retry setting on a host:
apt-config dump | grep -i 'Acquire::Retries'

# Update apt immediately, before any other package:
apt-get update
apt-get install --only-upgrade apt

The stakes are not theoretical. A package installed as root can plant a backdoor, tamper with system binaries, or exfiltrate secrets. For a production server or a build machine, that is the complete compromise of the software supply chain.

Who is exposed, and who is not

The scope is subtler than a blanket “everyone.” Debian and Ubuntu have each published a precise map.

• Debian: bookworm (12) moves from 2.6.1 to 2.6.2 (DLA-4880-1), trixie (13) from 3.0.3 to 3.0.4 (DSA-6607-1), and sid receives 3.3.6. At publication time, the testing branch (forky) was still running the vulnerable 3.3.5.
• Ubuntu: fixes published at 14:25 UTC for 26.10 (3.3.3ubuntu0.1), 26.04 LTS (3.2.1ubuntu0.1), 24.04 LTS (2.8.4ubuntu0.1), and 22.04 LTS (2.4.15ubuntu0.1). Ubuntu Pro already covers 14.04 LTS.
• Debian 11 and Ubuntu 20.04 are not exposed by default, because automatic retry is disabled there. But APT warns that many operational scripts turn on Acquire::Retries manually on those releases anyway, which makes them vulnerable too.

The long tail is where the risk concentrates. Debian 11’s free LTS window closed on August 31, so the 2.2.5 fix APT published targets a release many fleets have still not migrated off. An organization running Debian 11 or Ubuntu 20.04 in production now faces a dilemma: keep the default dormant state and hope no provisioning script flips Acquire::Retries on, or migrate to a release that receives the fix by default. That toggle, common in automation, is what silently moves those hosts from “safe” to “exposed.”

Ubuntu rates the flaw high priority with a CVSS 4.0 score of 7.7, and notes that all distributions built on Debian or Ubuntu are affected, without naming them.

One point deserves attention: none of the three advisories — Debian, Ubuntu, APT — describes exploitation in the wild. The flaw was reported by Max Justicz through coordinated disclosure. For now the patch precedes public exploitation; that is exactly the window in which a fleet must patch before the first exploit circulates.

What to do

The response comes down to three moves, in priority order.

• Update apt everywhere, now. The fix has no other dependency: it is the apt package itself that changes. Roll it out first, ahead of any other patch.
• Move sources to HTTPS. The flaw is described over HTTP, and the advisories do not yet rule on the exposure of HTTPS sources. Even if HTTPS is not always enough — a compromised mirror can still speak HTTPS — it removes the class of attackers who merely sit on-path on the network.
• Audit Acquire::Retries and your mirrors. On older releases where retry is disabled by default, check that no script re-enabled it. And inventory your internal mirrors and proxies: an attacker who owns your proxy now owns your install chain.

There is no documented workaround for systems that cannot update immediately — all three advisories are explicit on that point. For those machines, the only remaining lever is at the network level: pin your sources to trusted mirrors, disable retry (Acquire::Retries "0"), and, if your infrastructure allows it, force APT traffic through a trusted HTTPS proxy you control. These are palliatives, not fixes: the only real way out is updating apt.

How to verify you are patched

Once the update is applied, two quick checks confirm the fix is actually live.

# apt package version (>= 2.6.2, 3.0.4, or 3.3.6 depending on branch):
apt-cache policy apt

# Make sure no forced retry is lingering in the configuration:
apt-config dump | grep -i 'Acquire::Retries'

Beyond the version number, remember what the flaw does not change: APT remains a trust anchor. Fixing it does not excuse you from watching your logs (/var/log/apt/history.log) or from locking down your mirrors with signed repositories and a controlled source list. An install chain is a system: the package manager is only its first link. This flaw also belongs to the TOCTOU family — time-of-check to time-of-use — where the check and the use of a value are separated by a window an attacker can exploit; that class recurs, and today’s patch does not extinguish its generic cause.

Verdict

This flaw is a reminder that package signing is not an option but a load-bearing pillar — and that a pillar can crack suddenly over a single re-verification mistake. The fix is trivial to apply, and no exploitation is documented to date: the window to patch cleanly is open.

If you run a Debian or Ubuntu fleet, update apt today and switch your sources to HTTPS; the cost is one command, the risk avoided is root compromise of your entire install chain. If you maintain an internal mirror or proxy, treat it as an attack surface: it is now the equivalent of a machine that hands binaries to your whole fleet. The real question is no longer “am I exposed,” but “is my apt already updated.”

References

• The Hacker News — Debian and Ubuntu APT Flaw Lets MitM Attackers Swap Verified Packages and Run Code as Root (November 4, 2026)
• Debian Security Tracker — CVE-2026-109518
• Ubuntu Security — CVE-2026-109518