APT Retry Path Opens Root-Level Package Swap

The package manager is the part of a Linux system that most administrators extend the most trust to. It fetches software over the network, checks it against signatures, and hands it to the system with root privileges. According to advisories published on November 4, an attacker positioned on that network path can abuse a retry mechanism in APT to get their own code installed instead.

Debian, Ubuntu and APT's developers all published notices for the flaw on the same day, and each release describes an attacker who can alter package downloads swapping a verified package for one of their choosing. The substituted code then executes as root.

What the attacker actually changes

Ubuntu's advisory is explicit about who can carry out the attack: anyone able to modify the HTTP traffic between APT and the package server. That includes a malicious mirror or a malicious proxy sitting between the machine and the repository. No stolen key and no compromised repository are required to initiate the retry — the attacker only needs to be able to answer the client's requests.

The mechanism matters. APT is designed to retry a failed download, and the attacker induces those failures deliberately. APT's developers say the technique relies on HTTP redirects and ordinary temporary server errors to make APT attempt the download again. On that second attempt, the attacker supplies their own package in place of the one being fetched.

The result is a substitution that happens after the client has already committed to fetching a package it believes is legitimate. The install proceeds, and the attacker's payload lands with the privileges the package manager runs under.

Retries are on by default now

The exposure depends heavily on how APT is configured. The attack requires APT to retry failed downloads, and that behavior is the default from Debian 12 and Ubuntu 22.04 onward.

Ubuntu states that older releases, including Debian 11 and Ubuntu 20.04, are not exposed by default. APT's developers nonetheless point out a caveat: many user scripts may have enabled the retry setting, Acquire::Retries, on those older releases anyway. A system that is safe out of the box may not be safe after local configuration has been applied.

That distinction is the difference between a fleet that needs no action and one that needs an audit of its APT configuration before anyone can say it is unaffected.

Severity: critical on one side, high on the other

The two distributions do not describe the flaw in identical terms. APT's developers call it critical. Ubuntu rates it high priority and assigns it a CVSS 4.0 score of 7.7.

Ubuntu also states that distributions built on Debian and Ubuntu are affected as well, though its advisory does not name any of them. Operators of downstream or derivative distributions therefore have no list to check against from the advisory itself and must establish their own exposure.

The identifier used across the response is CVE-2026-109518, and Debian has released fixed versions of APT to address it.

The fixed builds, as published

Ubuntu pushed new APT builds to its security archive at 14:25 UTC on November 4, covering four of its releases:

• 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

APT's developers say updates for Ubuntu and its Ubuntu Pro subscription service are being released, and that Ubuntu 14.04 users with Ubuntu Pro can already obtain one. Later on publication day, at 15:46 UTC, Ubuntu still marked all eight releases it tracks for the flaw, from 14.04 LTS to 26.10, as vulnerable.

On the Debian side, a fixed version exists for the older branch: APT's developers have published version 2.2.5 for Debian 11, whose long-term support ended on August 31. Separately, Debian's testing branch was still on the vulnerable version 3.3.5 at 14:58 UTC on November 4.

None of the three advisories describes attacks exploiting the flaw. None of them offers a workaround for systems that cannot be updated yet. And all three describe the attack over HTTP; they do not say whether package sources reached over HTTPS are exposed.

The reporting credit and the gaps

The flaw was reported by Max Justicz, according to the advisories. Beyond that credit, the notices are narrow in scope: they describe the mechanism, the affected versions and the fixed builds, and they stop there.

That leaves several practical questions unanswered by the source material. Whether a given downstream distribution has shipped a fix is not enumerated. Whether the retry behavior can be disabled as a stopgap is not stated — no workaround is offered at all. And the HTTPS question, which determines whether encrypted transport alone is sufficient protection, is explicitly left open by the advisories' silence.

Why it matters for anyone running APT

The uncomfortable part of this flaw is where it sits in the trust chain. Package verification is the control that administrators rely on to know that what they install came from the distribution and not from someone in the middle. This attack does not defeat verification by breaking cryptography; per the advisories, it works because the download can be made to happen more than once, and the retry is the opening.

For operators, the immediate action is to identify which systems have the fixed builds available and apply them, and to check older releases for local configuration that turned retries on. For those who cannot update yet, the advisories offer nothing, which suggests the window between publication and patching is one where exposure has to be managed by other means — or accepted.

For the wider ecosystem, the unanswered HTTPS question is the one to watch. If encrypted transport turns out to close the path, the fix for many organizations may be a configuration change rather than a code change. If it does not, the lesson is that the transport controls surrounding a package manager deserve the same attention as the package manager's own verification logic.