We tell everyone to keep their systems updated. Fair. But updates are just software arriving over a network from somewhere else, and this week Debian and Ubuntu reminded us the delivery truck can be hijacked too.
What Happened
On November 4, Debian and Ubuntu published fixes for CVE-2026-109518 in APT, the package manager that installs and updates software on pretty much every Debian and Ubuntu box on the planet. It was reported by Max Justicz.
Debian's description: an on-path attacker "who can manipulate the HTTP traffic (including a malicious mirror or proxy)" between APT and an archive server can trick APT into installing an attacker-controlled, unverified package and "achieve remote code execution with root privileges."
The short version of how: by mixing HTTP redirects and temporary server errors, the attacker forces APT to retry a download, and a flaw in how APT reuses files during that retry lets a verified package get swapped for the attacker's. The Hacker News quotes the APT advisory: it "allows an attacker who can modify package downloads to swap a checked package for their own."
Ubuntu scores it 7.7 (CVSS 4.0) and APT's developers call it critical. None of the advisories describe exploitation in the wild.
Who's Affected
The attack needs APT's retry feature, which is on by default (three retries) starting with Debian 12 and Ubuntu 22.04. Older releases aren't affected in their default configuration, though a script that sets Acquire::Retries changes that.
Fixed versions:
- Debian 12 (bookworm): apt 2.6.2
- Debian 13 (trixie): apt 3.0.4
- Ubuntu 26.04 LTS: 3.2.1ubuntu0.1
- Ubuntu 24.04 LTS: 2.8.4ubuntu0.1
- Ubuntu 22.04 LTS: 2.4.15ubuntu0.1
There's no workaround published for systems that can't update yet.
The Bigger Point
The whole design of APT is that you don't have to trust the mirror, because the packages are signed. That's what makes plain HTTP mirrors "fine." This bug is the gap between "the signature checked out" and "the file that got installed is the file that was checked." Signing is necessary. It isn't the whole story.
Here's the zero trust lesson, and it isn't really about any product (usual disclosure: I work at Zscaler, so weigh my bias): trust shouldn't come from one control. Signed packages, encrypted transport, a known mirror, and restricted egress each cover a different failure. When one breaks, like signing did here, the others are still standing.
Ask yourself how your servers get their updates today:
- Over HTTP to a public mirror?
- Through a proxy or cache that a lot of people can touch?
- From any internet destination, because "servers need updates" turned into an allow-all egress rule years ago?
Each of those is a place an on-path attacker can sit.
What To Do
- Patch APT first, then do the rest of your updates. Fixing the updater before you trust it with anything else is the right order.
- Use HTTPS mirrors. Debian and Ubuntu both support them. It shrinks the set of people who can tamper with the download to the mirror itself.
- Run an internal mirror or artifact proxy you control, and point servers at it instead of the internet.
- Lock down server egress. Production servers should reach the package sources they need, not everything.
- Treat build and CI runners the same way. A container build that runs
apt-get installover HTTP is a supply chain step, and it often runs with fewer controls than production.
Bottom Line
The update process is part of your attack surface, not a trusted pipe that sits outside it. Patch APT, move to HTTPS mirrors, and stop letting servers talk to the whole internet just because they occasionally need a package.
Sources: OSV, DEBIAN-CVE-2026-109518, Debian security advisory, Ubuntu CVE-2026-109518, and The Hacker News