Ubuntu and Debian Patched an APT Bug That Can Hand a Malicious Mirror Root. The Trigger Is a Setting That Has Been On by Default Since Ubuntu 22.04.
Ubuntu and Debian shipped fixes on November 4 for CVE-2026-109518, an APT bug that lets an on-path attacker on HTTP package traffic, including a malicious mirror or proxy, trick a machine into installing an attacker-controlled package that was never verified, with root privileges. Ubuntu rates it High at CVSS 7.7. The detail that matters for solo operators is the precondition: the client has to retry failed downloads, and a retry count of 3 has been the default since Debian 12 (bookworm) and Ubuntu 22.04 LTS. If your VPS, CI runner or Docker base image is newer than that, you are in the default-affected group until apt is updated.
What the bug needs
The advisory text is short and specific. Max Justicz found that APT "incorrectly handled hard links when encountering redirects and retrying package downloads." In practice that means three things have to line up. Someone has to sit between your machine and the archive and be able to change HTTP traffic. Your client has to follow a redirect. And it has to retry the download, which only happens when Acquire::Retries is set to something other than zero.
Older releases are unaffected in a default configuration because they did not retry by default. Newer ones did, which is why I would not treat this as an exotic bug for exotic setups. The default is the risky path.
Two caveats I want to be honest about. First, none of the three advisories I read say whether package sources reached over HTTPS are exposed. Signed repositories over HTTPS make the on-path part much harder, but I would not assume immunity from an advisory that doesn't claim it. Second, none of them describe attacks in the wild. This is a patch-this-week bug, not a drop-everything bug.
Who is realistically exposed
A big company runs its own mirrors and controls the network. A solo builder usually does neither. Here is where I would look:
Pretty much any stock install. Debian and Ubuntu have long shipped http:// archive URLs by default and lean on package signatures for integrity, and many hosting providers swap in their own mirror, also over HTTP. That is normally fine. This bug is the exception, because the unverified package is the whole point. Run step 3 below and see what your boxes say.
CI runners and build containers. Every RUN apt-get update && apt-get install in a Dockerfile is a fresh install from whatever mirror the base image points to, and it often runs on shared infrastructure you have never looked at.
Coffee shop and hotel networks if you run Debian or Ubuntu on a laptop. That is the textbook on-path attacker.
The fixed versions
These are the versions from Ubuntu's USN-8996-1 and the Debian security tracker. If apt on your machine is at or above the number for your release, you have the fix.
Ubuntu 26.04 LTS: 3.2.1ubuntu0.1. Ubuntu 24.04 LTS: 2.8.4ubuntu0.1. Ubuntu 22.04 LTS: 2.4.15ubuntu0.1. Ubuntu 26.10: 3.3.3ubuntu0.1. Ubuntu 20.04 and older LTS releases get fixes through Ubuntu Pro (2.0.12+esm1 for 20.04).
Debian 13 (trixie): 3.0.4 via DSA-6607-1. Debian 12 (bookworm): 2.6.2 via DLA-4880-1. Debian testing and unstable are fixed in 3.3.6 and 3.3.7.
The check I'd run on each box
This takes about two minutes per server. I run it over SSH, then once inside a throwaway container of each base image I build from.
# 1. Which apt do I have? apt-cache policy apt | head -3 # 2. Is retry on? (empty output means the built-in default applies) apt-config dump | grep -i retries # 3. Are any sources plain HTTP? grep -rhE '^(deb|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null | grep -i 'http://' # 4. Patch sudo apt-get update && sudo apt-get install --only-upgrade apt
There is a mildly awkward moment in step 4: you are updating APT using APT, over the same mirror. I do it from a network I trust (not the hotel), and on servers I don't worry much because the attacker would have to be on that path at that exact minute.
For Docker, the fix is boring. Rebuild your images with a fresh base pull. If you pin base images by digest, which I recommend, bump the digest. An image built last month has last month's apt, even if the host is patched.
If you can't update a machine today, setting Acquire::Retries "0"; in a file under /etc/apt/apt.conf.d/ should remove the precondition the advisories describe. I want to be clear that this is my reading of the advisory, not a vendor-recommended workaround. None of the advisories offer one. I would use it as a stopgap for a day, not a fix.
What I'd actually do
Patch every Debian and Ubuntu box you own this week, rebuild every container image that starts FROM debian or FROM ubuntu, and while you are in there, switch any http:// sources to HTTPS mirrors. That last part is the real lesson. This bug only matters if someone can touch your package traffic, and plain HTTP to a provider mirror is an open invitation. You fixed the bug in ten minutes. Fixing the transport fixes the next one too.
Where I could be wrong: if your provider mirror is on a private network inside the same data center, the realistic attacker is the provider itself, and the urgency drops. I would still patch. A 7.7 with root at the end of it is not something I want to argue about with myself on a Friday.
Author
Lukas
@lukcombinator