An APT retry could bypass package verification

A package manager is supposed to do the suspicious part of installing software on your behalf. It checks the download before giving the package a chance to run installation scripts. CVE-2026-109518 could undermine that check in APT, the package manager used by Ubuntu and Debian. Those distributions published fixes on November 4, 2026. AWS followed on November 5 with guidance for customers who use them on EC2 or in container images. [1] [2] [3] [5]

Where a retry can change the file

Debian describes a failure that can start when an HTTP redirect makes two package downloads share a download address. The affected code can reuse a hard link, another name for the same underlying file. If a transfer is retried, bytes written through one name can replace the contents APT already verified through the other. APT can then install the replacement. Package installation scripts can run as root, so the consequence is more serious than a broken download. [2] [5] [7]

Exploitation requires a package installation, an affected HTTP download path, enabled retries and someone able to manipulate traffic between APT and the archive server. Canonical includes a malicious mirror or proxy in that description. A nonzero retry setting became the default with Ubuntu 22.04 LTS and Debian 12. An older system can still meet that condition if a script or local configuration enables retries. [2] [4] [7]

Imagine a build worker that installs packages from a mirror each time it creates a web application image. A retry is normally the dullest part of the build. In this case the mirror and the worker's APT revision matter because the installation runs before the application image reaches a developer or a production server. The same question applies to a Linux instance that installs packages after launch.

The fixed number depends on the distribution

Canonical lists apt 2.4.15ubuntu0.1 for Ubuntu 22.04 LTS, 2.8.4ubuntu0.1 for 24.04 LTS, 3.2.1ubuntu0.1 for 26.04 LTS and 3.3.3ubuntu0.1 for 26.10. Its notice also lists the applicable Ubuntu Pro packages for older releases. Debian lists apt 2.6.2 for Debian 12 Bookworm and 3.0.4 for Debian 13 Trixie. Check the package revision for the distribution and release actually installed. [3] [4] [5] [6]

Canonical and AWS recommend temporarily setting APT's retry option to zero when applying the update. Canonical explains that HTTPS protects against someone altering unencrypted traffic in transit, and recommends installing the fix as well. The actual package sources matter here. A build may use an internal mirror or a proxy rather than the public mirror a person remembers configuring. Follow the distribution's instructions for the affected release. [1] [2]

The patch has to reach the next build, too

AWS calls out Ubuntu and Debian on EC2 and in container images, including customers using its Ubuntu 22.04 machine image. Our reading for a team with a mix of deployments is to track the package on running machines and in the inputs used to make new ones. An updated server can coexist with a launch image or build worker that still starts with an older copy. A successful image build does not tell you which APT revision performed the install. [1]

During a container build, the relevant copy of APT may live in a stage that never ships. In the hypothetical build workflow, the retry happens on the worker while assembling the image. The final image's inventory and the build log answer different questions. Keep the APT revision used during the build with the resulting image, especially when rebuilding from a pinned base.

For the example web application, it helps to keep the fixed package revision with the base image and build record. Check that a new instance and a rebuilt container pick up the intended package through the expected source. That separates a completed rollout from a successful update on the first machine someone checked.

The November notices describe a specific way verification can fail. Assessing a particular fleet starts with the systems that install packages, the APT revisions they run, and the repositories and retry settings those installs actually use. Those are details a team can check even when the application itself had no code changes. [1] [2] [4]