Debian, Ubuntu and the APT maintainers disclosed CVE-2026-109518 on November 4: a flaw in how APT handles HTTP redirects and retried downloads that lets an attacker who can tamper with package traffic replace a package after APT has verified it. The substituted package is then installed by dpkg as root. The APT developers describe the bug as critical; Ubuntu rates it High (CVSS 4.0 7.7).

What happens

APT’s security model is “verify, then install”: the .deb hash is checked against the signed repository metadata before it is handed to dpkg. This bug breaks the ordering between verification and use.

Per the Debian and Ubuntu advisories and public write-ups, the issue combines three behaviours:

  • APT can merge two download items when an HTTP redirect causes them to resolve to the same URI.
  • The retry path for interrupted or failed transfers mishandles files on disk, including hard links created during redirect handling.
  • A resumed or retried transfer can therefore write through to a file that has already passed verification, overwriting the checked package contents with attacker-supplied data.

The result is a time-of-check/time-of-use gap on the downloaded archive. The signature chain is not forged; the bytes that were verified are simply not the bytes that get installed.

Preconditions

This is not a remote, unauthenticated bug against an arbitrary host. The attacker needs to alter the HTTP responses the client sees, for example:

  • a malicious or compromised mirror,
  • a transparent or hostile proxy on the path,
  • an on-path position on plain-HTTP repository traffic (Debian and Ubuntu mirrors commonly use HTTP because the metadata is signed).

The vulnerable code path also requires Acquire::Retries to be non-zero. That has been the default (3) since apt 2.3.2, so Debian 12 and Ubuntu 22.04 and later are exposed out of the box. Older releases are mainly exposed where retries were enabled manually, which is common in CI images and provisioning scripts.

Impact

Any system that runs apt update && apt install against a network it does not fully control is in scope: cloud images bootstrapping at first boot, container builds (RUN apt-get install), CI runners, and fleets pulling from internal mirrors over HTTP. Because the swap occurs at install time, the attacker’s payload runs with root in package maintainer scripts. For container builds this means a poisoned image layer that looks like a legitimate, signed install. No in-the-wild exploitation has been reported at the time of writing.

Fixed versions

Reported fixed releases include apt 2.6.2 (Debian 12) and 3.0.4 (Debian 13), with updates for supported Ubuntu releases (for example 2.4.15ubuntu0.1 on 22.04). Vendor-reported version lists differ slightly between secondary sources, and Debian testing was reported as still vulnerable at the time of the disclosure. Confirm against the Debian security tracker and the Ubuntu security notice for your release rather than relying on a third-party list.

What to do now

  1. Update apt on every Debian and Ubuntu host, base image and CI runner, and rebuild container images that were built on unpatched tooling over untrusted networks.
  2. Stopgap if you cannot patch immediately: set Acquire::Retries "0"; in /etc/apt/apt.conf.d/. This removes the vulnerable retry path at the cost of resilience on flaky links.
  3. Use HTTPS for repository sources and pin internal mirrors, so an on-path attacker cannot rewrite responses.
  4. Audit mirrors and proxies you operate, since a compromised mirror is the simplest delivery vector.
  5. Check recent package installs on hosts that bootstrap over untrusted networks: compare installed .deb hashes (debsums, dpkg -V) against the archive.

References