Debian and Ubuntu Patch APT Flaw CVE-2026-109518, Which Lets an On-Path Attacker or Malicious Mirror Run Code as Root, and Ubuntu Advises Installing the Fix With Retries Turned Off

Ubuntu and Debian disclosed CVE-2026-109518 on November 4 and released fixed packages for it. The flaw is in APT, the package manager behind apt, apt-get and aptitude: an attacker on the network path, or one running a package mirror or proxy, can get code running as root on a machine while it installs packages. The researcher credited in the notices, Max Justicz, reported it, and Canonical’s CVE record scores it 7.7 (High) on CVSS 4.0. Debian’s advisory DSA-6607-1 puts the fix in APT 3.0.4 for Debian 13 (trixie), its LTS advisory DLA-4880-1 covers Debian 12 (bookworm) in 2.6.2, and Ubuntu’s USN-8996-1 covers every release from 14.04 LTS to 26.10.

Two details decide how fast an administrator needs to move. The on-path attack needs plain HTTP, and the attack as described needs the client to retry a failed download, which APT has done by default since version 2.3.2 (so on Debian 12 and Ubuntu 22.04 and later). And because the fix is itself a package that APT fetches, Ubuntu tells administrators to install it with retries turned off. We read Ubuntu’s blog post and notice, Debian’s advisory as quoted on oss-security, the CVE and NVD records, and the source code of APT 3.0.3 and 3.0.4 to see what the fix changes. We did not run an exploit, and none of the sources reports attacks in the wild.

At a glance

What the advisories say

Ubuntu’s blog post, written by Luci Stanescu, says: “An on-path attacker who can manipulate the HTTP traffic between a system and an archive server can trigger the installation of an attacker-controlled .deb package file and obtain root privileges on the target system.” It adds that the flaw “exists in the HTTP backend invoked by the APT library, and affects any APT-based frontend (apt, apt-get, aptitude, or any of the Ubuntu graphical applications),” and that the attacker needs one thing from the client: “The vulnerability requires the client to retry a failed download.” The notice USN-8996-1 describes the cause as APT having “incorrectly handled hard links when encountering redirects and retrying package downloads.”

Debian’s advisory reads differently. Jan Schaumann posted it to oss-security at 15:55 US Eastern time on November 4 (20:55 UTC) because it “seems worth sharing more widely.” It says: “APT can merge two different package downloads after an HTTP redirect gives them the same URI. Improper file handling when resuming an HTTP download allows a man-in-the-middle attacker to replace a package after verification, resulting in the execution of arbitrary code as root.” For Debian 13 it says the problem is fixed in 3.0.4 and that “Additionally this update addresses several out-of-bounds access issues.”

Canonical, which assigned the CVE, wrote the record: “The vulnerability is caused by the reuse of hard links and requires the client to follow redirects and retry the download of package files.” The record’s description also covers a “malicious mirror or proxy,” not only a network attacker.

Three descriptions of the bypass

These are not quite the same claim. The first says a package that fails verification gets installed. The last says a package that passed verification is changed afterward. On our reading of the fix, in the next section, the second and third fit better: the fix changes how download files are opened and leaves the hash and signature checks alone.

What the fix changes, from the source

We downloaded the APT 3.0.3 source package from Debian’s main archive and the 3.0.4 security release from security.debian.org, then compared them with diff -ru. The 3.0.4 changelog lists the fix for this CVE under “SECURITY UPDATE: Download verification bypass” as “methods/*.cc: Open target files exclusively,” and in the diff it lands in three download methods: http, rred and store. The rest of the diff holds the out-of-bounds fixes listed separately, a log message that moved behind the debug flag, version strings, translation templates, and test and CI files. Nothing in it touches hash comparison; the only change in the gpgv method is one of the out-of-bounds fixes.

Three pieces of the 3.0.3 code explain the CVE’s wording. First, when several download items share one URI, pkgAcquire::Queue::Enqueue in acquire.cc keeps them as owners of a single queue entry. When the entry finishes or fails and the first owner’s file exists, Worker::PrepareFiles in acquire-worker.cc removes every other owner’s destination file and creates a hard link to the first owner’s file, falling back to a symlink only if linking fails. Second, the HTTP method opened its destination with FileFd::WriteAny, which is read-write plus create: it neither truncates the file nor removes an existing one, so it writes into whatever file already sits at that path. Third, a retry can resume a partial download, which the 3.0.4 code now handles explicitly. Put together, a destination name that is a hard link to another download’s file would write into that other file’s contents. That is our inference from public source. We did not test it, and neither vendor has published exploit steps.

In 3.0.4 the HTTP method adds the exclusive flag, and a code comment says why: “Open the file exclusively to avoid injection attacks by links.” The diff below is abridged to the changed open call and its comment.

--- apt-3.0.3/methods/http.cc
+++ apt-3.0.4/methods/http.cc
-   if (Req.File.Open(Queue->DestFile, FileFd::WriteAny) == false)
+   // Open the file exclusively to avoid injection attacks by links
+   if (Req.File.Open(Queue->DestFile, FileFd::WriteAny | FileFd::Exclusive) == false)

In FileFd::Open, a create-plus-exclusive open first removes any existing file at that path and then creates a new one with O_EXCL, so the new file cannot share storage with another download’s file. A resumed download still needs its earlier bytes, so the new code first opens the old partial file read-only, creates the fresh file, and copies the old content across, with the comment “The exclusive open unlinked the old file; copy its content into the new one and rewind for hashing.” The rred and store methods swap FileFd::Empty for the exclusive flag in the same way. The record’s two weakness types match this reading: CWE-62 is a UNIX hard link problem and CWE-367 is a time-of-check time-of-use race.

Who is exposed

Ubuntu ties the flaw to the Acquire::Retries setting, which it says “is only set to a non-zero value in Ubuntu 22.04 LTS (Jammy Jellyfish) and newer releases.” APT’s own changelog dates that default to version 2.3.2, April 23, 2021: “Enable the Acquire::Retries option by default, set to 3.” The CVE record agrees that 3 is the default “starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS (Jammy Jellyfish), so older releases are unaffected in a default configuration.” The APT team adds a caution, relayed on oss-security: retries “has only been the default since APT 2.3.2,” but “many user scripts may have been using it in older releases.”

Redirects are part of the condition, and they are ordinary on these networks. Debian’s mirror page says: “If you hit the server behind deb.debian.org directly, either because you use an older apt or because you use a HTTP proxy that does not support SRV records, your requests will get HTTP redirected to one of the CDN instances.” A client that follows redirects is not an unusual client.

The on-path version also needs plain HTTP. The same Debian page shows deb http://deb.debian.org/debian as its example sources line, and the HTTPS-switch command Ubuntu publishes rewrites http:// URLs for archive.ubuntu.com, security.ubuntu.com and ports.ubuntu.com, which suggests plain HTTP is still how many systems reach them. All four main archive hosts, archive.ubuntu.com, security.ubuntu.com, deb.debian.org and security.debian.org, answered HTTPS requests for their release files when we tried them on November 5 (HTTP 200 on each).

Our reading is that the exposure is any APT run on a network or through a mirror you do not control, with default retries: laptops on public Wi-Fi, the first package upgrade on a new cloud server, and container or CI builds that run apt-get install over HTTP. We tested none of those. Ubuntu notes that snap installs are not affected. For scale, the researcher’s 2019 demonstration of an earlier APT flaw was itself a Dockerfile build.

Fixed versions

How to install the fix

Ubuntu’s blog post gives two upgrade commands, both with retries switched off for that one run. The -o option sets a configuration option for a single invocation, as the apt-get manual page describes. The first command upgrades every package; the second upgrades only APT.

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

Ubuntu says “Temporarily setting Acquire::Retries to zero while installing this security update provides a mitigation against this vulnerability, whether exploited by an on-path attacker or a potentially malicious mirror.” The option is generic APT configuration, so the same one-run form works on Debian, where the advisory text we have gives no workaround. Schaumann’s suggestion for a persistent setting is to add Acquire::Retries 0; to apt.conf, which “may mitigate the issue until you upgrade.” Retries also smooth over flaky networks, so the fix, not the setting, is the durable answer.

To check the result, apt-cache policy apt shows the installed and candidate versions to compare with the table, and Ubuntu’s own check is apt list --installed '?source-package(^apt$)'.

Switching to HTTPS first

Where an on-path attacker is the worry, Ubuntu suggests moving the sources to HTTPS before installing the update. Its command rewrites the Ubuntu archive hosts only:

sudo sed -Ei 's!http://((([a-z]+\.)?archive|security|ports)\.ubuntu\.com)!https://\1!' /etc/apt/sources.list /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources
sudo apt update

We ran the command with GNU sed 4.9 on sample lines in the one-line format and the newer URIs: format. Lines for archive.ubuntu.com, a country mirror such as us.archive.ubuntu.com, security.ubuntu.com and ports.ubuntu.com changed to HTTPS, while a PPA line, a third-party mirror line and a line already on HTTPS stayed as they were. Ubuntu warns that the command does not touch other mirrors or repositories, and that “some mirrors operated by the community, including some country-specific mirrors, do not support HTTPS,” so the apt update that follows should finish without errors. It says that once the flaw is patched, enabling TLS is “only necessary as a future precaution,” and that the archive signature scheme remains “a much stronger integrity protection safeguard.” Ubuntu describes TLS as protection against the on-path attacker and the retries setting as covering a malicious mirror too.

Automatic updates

Ubuntu says that where unattended upgrades are enabled, “the patches above will be automatically applied within 24 hours of being available.” It does not mention the retry setting for that automatic run. On a system that reaches its mirror over HTTP across a network you do not control, the cautious route is to switch to HTTPS first or to upgrade by hand with retries off.

What the sources do not say

• Exploitation and proof of concept. None of the sources reports attacks. CISA’s catalog does not list the CVE, and its SSVC entry in the NVD record gives exploitation as none. We found no public proof of concept and no write-up by the researcher.
• Timeline. The CVE ID was reserved on October 12, nearly 23 days before the record was published, and the changelogs of the fixed Debian and Ubuntu packages are dated November 2. No source says when the researcher reported the bug or how long coordination ran.
• Severity. The 7.7 score is Canonical’s alone while NVD’s analysis is pending.
• The other fixes. Debian says the update addresses “several out-of-bounds access issues.” The 3.0.4 changelog lists six under “SECURITY UPDATE: Out-of-bounds accesses” (Ubuntu’s 24.04 build lists five), and Debian’s tracker page for the apt package shows no other 2026 CVE. Ubuntu’s notice covers only CVE-2026-109518, so a scanner that matches on CVE IDs will not flag them, but installing the update brings them in.
• Reach. The fix also changes the rred and store methods. The notices describe exploitation only through a package install and do not say whether those two methods can be reached.
• Debian’s own pages. Debian’s advisory pages and mailing-list archives answered our scripted requests with a bot-check page, so the Debian advisory and the APT team’s remarks come from Schaumann’s quotes of them on oss-security.

Our reading

The fix is small and the lesson is old. APT’s signatures protect what a mirror serves, but according to Debian this attack changes a file after the check, and our reading of the code puts the cause in how download files are shared and reopened. A signed archive does not help once a file can be rewritten underneath APT. That is why both vendors’ interim advice removes a transport condition, plain HTTP or retries, instead of touching signatures.

It is not the first time. In January 2019 Max Justicz published a write-up of CVE-2019-3462, an earlier flaw in APT’s HTTP redirect handling, saying he had “found a vulnerability in apt that allows a network man-in-the-middle (or a malicious package mirror) to execute arbitrary code as root on a machine installing any package.” His advice then also targeted the update path: “you can protect yourself by disabling HTTP redirects while you update.” Seven years later the notices credit the same name, and the interim advice is again to switch off a transport feature for the length of the update, because the repair has to travel through the tool being repaired.

For administrators the practical order is short. Put systems that fetch packages over HTTP across networks you do not control first in line. Upgrade APT by hand, over HTTPS or with retries off, instead of waiting for an automatic run. And treat the update as bigger than one CVE, since it carries six out-of-bounds fixes that have no CVE ID we could find. For other recent patch stories on Linux distributions, see our reports on the Linux TCP flaw whose patched kernels were still pending at Red Hat and Ubuntu, the Brotli flaw rated from Medium to Critical across vendors and the PHP release that shipped a day early after a leak.

Sources and related coverage

• Ubuntu, CVE-2026-109518 APT vulnerability fixes available (Luci Stanescu, November 4) and USN-8996-1, plus the changelog for apt 2.8.4ubuntu0.1.
• Jan Schaumann, CVE-2026-109518: RCE in apt(1) (DSA 6607-1) on oss-security, quoting Debian’s advisory and the APT team’s remarks.
• Debian security tracker entries for CVE-2026-109518, DSA-6607-1, DLA-4880-1 and the apt source package, and the deb.debian.org mirror page.
• APT source packages 3.0.3 (main archive) and 3.0.4 (security archive), including the 3.0.4 changelog.
• The CVE record, the NVD record and CISA’s Known Exploited Vulnerabilities catalog.
• Max Justicz, Remote Code Execution in apt/apt-get (January 22, 2019), and the tracker entry for CVE-2019-3462.
• Method: we compared the two source packages with diff -ru and read the code. We did not build or run APT or any exploit, and the machine we used runs Windows, so the only command we ran was Ubuntu’s sed line, on sample files. The version, record and HTTPS checks were made on November 5 between 10:10 and 10:25 UTC. A web search found no other coverage of the flaw.
• On sxz.io: the Linux TCP flaw behind Anthropic’s remote root exploit, the Brotli flaw and the PHP2Shell patch release.