APT can install a package that failed signature checks

What happened

Canonical says CVE-2026-109518 lets a remote on-path attacker install an unverified package and run code as root, because APT mishandled hard links during redirects and download retries (vendor, USN-8996-1). It rates the flaw High, CVSS 4.0 7.7 (vendor, Canonical).

The line that matters: the flaw "allows an attacker to trick APT into installing a package even if it fails signature verification" (vendor, Canonical). Most teams treat signed repositories as the control that makes HTTP mirrors acceptable. For this bug, it is not.

Max Justicz found it (independent, RuntimeWire). As of 5 November, ThreatDefence reports no exploitation, no public proof of concept, and no CISA KEV entry (independent, ThreatDefence). That reading will age, so check it before you rely on it.

Who is exposed

The attacker needs a position on the path to your mirror, or control of a mirror or proxy, and your client has to retry a failed download (vendor, Canonical). Three settings decide your row.

ThreatDefence also reports that cloud-init points Ubuntu at an HTTP archive by default (independent). Check your own sources.list rather than trust either assumption.

Fixed versions

We could not read Debian's own advisory, DSA-6607-1, so confirm the Debian rows there before you close the ticket.

Six steps

Prerequisites: an inventory of hosts, base images, and any apt proxy.

1. Step 1. Patch APT with retries off. The patch run itself uses the vulnerable client. Canonical's command: sudo apt update && sudo apt install -o Acquire::Retries=0 --only-upgrade '?source-package(^apt$)' (vendor). Owner: infrastructure lead.
2. Step 2. Rebuild golden images and base images. The apt in a base image is what later builds run (independent, ThreatDefence). A patched host does not patch the AMI behind it. Owner: platform engineering.
3. Step 3. Check CI runners. Any pipeline that runs apt-get on a shared network belongs on this list, including builds on images you do not own. Owner: DevOps lead.
4. Step 4. List your proxies. Run apt-config dump and look for Acquire::http::Proxy. ThreatDefence notes that caching proxies such as apt-cacher-ng sit in the path for every client, and that many stay on HTTP so caching works (independent). Owner: network lead.
5. Step 5. Move sources to HTTPS. Canonical publishes a command for Ubuntu archive sources and warns some community mirrors do not support HTTPS, so run apt update afterwards (vendor). Owner: infrastructure lead.
6. Step 6. Check derivatives. Proxmox, Mint, Raspberry Pi OS, and similar ship their own apt. Confirm with each vendor (independent, ThreatDefence). Owner: asset owner.

Signing packages is the distribution's job. Knowing which of your images still carry the old client is yours.

Trade-offs

• Set retries to 0 everywhere as a stopgap. Canonical says it prevents exploitation (vendor). It also removes the retry behaviour flaky networks rely on, so expect failed builds.
• Move everything to HTTPS. Closes this path. It can also break the caching that made an HTTP proxy worth running. Canonical still calls signatures the stronger integrity safeguard, since TLS only protects data in transit (vendor), so this adds a layer and replaces nothing.
• Patch on the normal cycle. Defensible for cloud hosts on private HTTPS mirrors, where an on-path position is hard to get. Not defensible for HTTP builds on shared networks.

Missing

• Debian's advisory, the Debian security tracker, and the maintainer notice. None would load for our tools, so Debian detail here is second-hand.
• Justicz's own write-up. We did not find it.
• Any proof of exploitation either way past 5 November.
• A test by Prestanda. We have not reproduced this flaw or run these steps in a client estate; the guidance comes from the sources above.