APT can check a package, then install a different one as root, Debian says of CVE-2026-109518

4 of 8 Ubuntu releases are exposed by default, and one setting decides it (derived)

Ubuntu's notice USN-8996-1 patches APT on 8 releases. Canonical's blog post says "Ubuntu 22.04 LTS (Jammy Jellyfish) and newer releases are affected by default". Counting the notice's own table, that is 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10: 4 of 8 (derived). The other 4, from 14.04 LTS to 20.04 LTS, are exposed only where someone has set Acquire::Retries above zero.

The flaw is CVE-2026-109518. Debian's DSA 6607-1 describes the result in one line: a "man-in-the-middle attacker" can "replace a package after verification, resulting in the execution of arbitrary code as root". Ubuntu says the signature scheme "normally secures package mirrors". On Debian's account the check ran, and the file changed afterwards.

That count says nothing about any attack. As read at 09:32 UTC on Sunday 8 November 2026, CVE-2026-109518 is not in CISA's Known Exploited Vulnerabilities catalogue (version 2026.11.06, released 6 November at 19:44 UTC, 1,769 entries). CISA's enrichment entry in the CVE record gives Exploitation "none", time stamped 4 November. Debian and Ubuntu do not say either way whether anyone has used it. The count also does not say how many machines fetch packages over plain HTTP, how many have an attacker anywhere near that path, or how many of the older machines have retries switched on.

The fixes were published on 4 November, 4 calendar days before this read (derived). Canonical reserved the CVE number on 12 October, 23 calendar days before publication (derived); no primary says when the flaw was reported. Canonical sells Ubuntu Pro, the channel through which the fixes for the four older releases are delivered.

What happened, in the words of the people who fixed it

A researcher reported the flaw to APT's maintainers; Canonical says it was "responsibly disclosed". The CVE record, assigned by Canonical as the numbering authority, titles it "APT RCE via hard link reuse" and classes it as CWE-62 (UNIX hard link) and CWE-367 (time-of-check time-of-use race condition). The record sets out four conditions (the count is derived): an attacker able to manipulate the HTTP traffic "(including a malicious mirror or proxy)"; traffic "triggered by a package install"; a client that will "follow redirects and retry the download of package files"; and a retry setting above zero.

Three primaries describe the middle of the chain, each in different words:

• Debian's advisory: "APT can merge two different package downloads after an HTTP redirect gives them the same URI", then "Improper file handling when resuming an HTTP download" allows the replacement.
• APT's maintainers, in their security post: redirects and "standard transient HTTP server errors that cause APT to retry downloads", leading APT to "override existing hardlinks with a chosen payload".
• Ubuntu's notice: "APT incorrectly handled hard links when encountering redirects and retrying package downloads".

Root follows from what a package is. Ubuntu says that when a system installs a .deb "it executes the package's scripts with root privileges". The maintainers call the result "the potential for remote code execution".

Zoom

No primary prints the exact sequence inside APT. Debian's tracker page names the fixing commit. This site has not read the patch and goes no further than the record.

Scope, on Canonical's word: the flaw is in the HTTP backend and "affects any APT-based frontend", including aptitude and Ubuntu's graphical tools. It "does not affect software installation via snap packages", and "Other transport methods (such as FTP) are not affected".

The order of publication on 4 November, in UTC: the maintainers' post at 12:00:16 (printed as 13:00:16 +0100), Debian's advisory at 12:07:32, Debian's LTS advisory at 12:46:36, the CVE record at 15:49:02. The maintainers' announcement that updates were available came 3 hours 48 minutes 46 seconds before the CVE record (derived).

A newer default widened the door. It did not build it

The record says "the value 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 tempting reading is that a recent default created the problem. The primaries do not support that:

• The record's affected ranges start at version 0 for both Debian and Ubuntu, well before the default changed.
• The maintainers say retries have "only been the default since APT 2.3.2", then warn that "many user scripts may have been using it in older releases".
• Ubuntu patched back to 14.04 LTS, and says older releases are "only affected if the Acquire::Retries APT configuration setting is set to a non-zero value".

The accurate version: the setting moved exposure from people who opted in to everyone on a current release. "Unaffected in a default configuration" describes a fresh install. It does not describe a machine that has spent years under a provisioning script.

Zoom

The ranges, counted. The record lists 21 affected ranges (derived): 13 under Debian and 8 under Ubuntu. Of those, 20 end in a lessThan value, which is the fixed version. One does not: Debian's entry from 1.8.3 ends lessThanOrEqual 1.8.5. That entry has an upper bound and no stated fix. The maintainers' list of fixed branches also goes from 1.8.2.4 straight to 2.0.12. No primary says why. Treat it as affected through 1.8.5 with no fixed version on the record.

Two traps for anyone reading the record with a scanner (this site's reading). First, the suffix. 6 of Ubuntu's 8 fixed strings are a Debian fixed number plus a suffix, for example 2.4.15 for Debian and 2.4.15ubuntu0.1 for Ubuntu, so a bare 2.4.15 on Ubuntu sits below the fix. The 3.3 series differs outright: 3.3.6 under Debian and 3.3.3ubuntu0.1 under Ubuntu. Match each host against its own distribution's entry. Second, the gaps. Each vendor's defaultStatus is "unaffected", so a version between listed ranges passes a literal reading. APT 2.3.2, the version the maintainers name as the start of the default, falls in no listed range. No primary says whether such versions are safe; the maintainers list only stable branches.

Who scored what, and what AT:P and UI:P mean here

AT:P, Attack Requirements: Present. FIRST's CVSS 4.0 specification uses this where "The successful attack depends on the presence of specific deployment and execution conditions", and gives two examples: "A race condition must be won" and network injection, meaning "vulnerabilities requiring an on-path attacker". Both fit a record that cites a time-of-check race and an attacker on the HTTP path. The value records that the attack cannot be launched from just anywhere.

UI:P, User Interaction: Passive. FIRST describes "limited interaction by the targeted user" and says "These interactions would be considered involuntary". One of its examples is "using an application which generates traffic over an untrusted or compromised network". Here, the record says the traffic is "triggered by a package install", and Canonical says an attacker can act "only if the target system attempts to install a .deb package".

Canonical publishes no reasoning for either value, so that mapping is this site's reading. One consequence is an inference, and is labelled as one: FIRST's definition allows "a separate user (or user-initiated process)", and Canonical says unattended upgrades are "enabled by default for Ubuntu 16.04 LTS onwards" and "Applies new security updates every 24 hours automatically". Passive here may mean a timer rather than a person. Canonical does not say whether those automatic runs are exposed before the fix lands.

Labels doing the work of a control

"Verified." Canonical says the signature scheme "remains a much stronger integrity protection" than TLS, and nothing here says the cryptography failed. A signature check protects the file that was checked. If a different file is installed, the check has answered the wrong question.

"Unaffected in a default configuration." A default belongs to a clean install. The maintainers' warning about user scripts is the reason to read your own configuration instead of the release number.

"HTTPS." Canonical's sentence is exact: "enabling TLS provides protection against this particular vulnerability when exploited by an on-path attacker". Its zero retries statement is wider, covering a case "whether exploited by an on-path attacker or a potentially malicious mirror". Encrypted delivery from a malicious mirror is still delivery from that mirror, so this site reads the HTTPS advice as covering the path and not the mirror. Canonical does not spell that out, and Debian's pages do not mention HTTPS at all.

What the primaries state, and what they do not

Where the sources differ

These stay as differences. This site does not resolve them.

What else the update carries, and what it leaves out

Debian's advisory says "Additionally this update addresses several out-of-bounds access issues". The maintainers' post lists 6 bundled fixes (derived count) and says "We do not expect any direct security impact outside denial of service" of third party applications that parse files across a privilege boundary, such as PackageKit. It also records a memory exhaustion fix for series 2.6, 2.8 and 3.0.

Two things are deliberately not fixed, on the maintainers' word. "Several out-of-bounds memory accesses exist in apt-ftparchive" stay, because of fix complexity and little testing in practice. And "An out-of-bounds access in the parser for build dependencies has not been fixed", because a rewrite carries too much regression risk. Anyone feeding untrusted .deb files to apt-ftparchive, or untrusted build dependency strings to that parser, should not assume this update covers them.

What to do, in order

Steps 1 to 4 are Canonical's advice for Ubuntu, except where marked. Debian's only instruction is "We recommend that you upgrade your apt packages". The rest are this site's suggestions.

Technical details

The condition. This is the record's sentence on the setting. It lives in APT configuration as Acquire::Retries. A defender checks whether any host sets it above zero, or inherits the default of 3.

It requires the client to have a non-zero Acquire::Retries configuration setting; the value 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 score. The vector as Canonical assigned it. AT:P and UI:P are explained above. Feed it to whatever computes your own environmental score.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

CISA's enrichment. The three decision points in the record. Exploitation carries a date and can change, so re-read it rather than quoting this copy later.

[
  {
    "Exploitation": "none"
  },
  {
    "Automatable": "no"
  },
  {
    "Technical Impact": "total"
  }
]
timestamp: 2026-11-04T00:00:00+00:00

The odd entry. The one range of 21 with no fixed version. Note lessThanOrEqual where every other entry has lessThan.

{
  "status": "affected",
  "version": "1.8.3",
  "lessThanOrEqual": "1.8.5",
  "versionType": "dpkg"
}

Fixed versions. Compare with the installed package. Layout is this site's; the version strings are as printed.

Ubuntu (USN-8996-1)
  26.10      stonking  apt 3.3.3ubuntu0.1
  26.04 LTS  resolute  apt 3.2.1ubuntu0.1
  24.04 LTS  noble     apt 2.8.4ubuntu0.1
  22.04 LTS  jammy     apt 2.4.15ubuntu0.1
  20.04 LTS  focal     apt 2.0.12+esm1
  18.04 LTS  bionic    apt 1.6.19+esm1
  16.04 LTS  xenial    apt 1.2.36+esm1
  14.04 LTS  trusty    apt 1.0.1ubuntu2.24+esm4

Debian
  bookworm (security)  2.6.2  DLA-4880-1
  trixie (security)    3.0.4  DSA-6607-1
  forky                3.3.6  tracker status: fixed
  sid                  3.3.7  tracker status: fixed (fixed version listed for unstable: 3.3.6)

Canonical's commands. Listing the installed version, then the recommended upgrade, then the fallback. These are Canonical's, for Ubuntu, and each sets retries to zero for that run only.

apt list --installed '?source-package(^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$)'

Canonical's HTTPS switch. Rewrites Ubuntu archive URLs in your sources files. Canonical notes it does not touch other mirrors or repositories. Run apt update afterwards.

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

The fixing commit. Debian's tracker names it for 3.3.6. Maintainers of derivative distributions can use it to check whether they carry the fix. This site has not read the commit.

5af16a8ad0f155233dfb10b7c92ad1903112ef79 (3.3.6)

A participant on the oss-security list separately suggested adding a zero retries line to apt.conf and wrote that it "may mitigate the issue until you upgrade". That is not Debian's or Ubuntu's advice. No primary prints attack traffic or exploit steps, and none appears here.

The question Debian and Ubuntu leave open

Every primary tells you how to stop this from now on. None tells you how to find out whether it already happened. If a machine installed a swapped package before it was patched, the package would have passed through the normal install path with root privileges, and neither Debian nor Ubuntu names any indicator, log line or check that would show it. For a host that has fetched packages over a network you do not control: what evidence do you have that the package you installed is the package you checked?

Key facts